Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jakarta EE 8 challenge, permissions.xml must also be added to EAR level #139

Closed
scottmarlow opened this issue Jan 8, 2020 · 6 comments
Closed
Labels
accepted Accepted certification or challenge request challenge TCK challenge

Comments

@scottmarlow
Copy link
Contributor

To correctly resolve a failure in com.sun.ts.tests.securityapi.ham.sam.obtainbean.Client#testSAMObtainBean, the securityapi/ham/sam/obtainbean/build.xml should be changed to include the permissions.xml in the EAR (should also keep permissions.xml at the WAR level).

This is wrong in Jakarta platform TCK versions 8.0 - 8.0.1, this can be seen with a change that we are testing for (Red Hat) WildFly, where we need this test to be corrected (e.g. likely via a minor build.xml change).

The securityapi/idstore/idstorepermission/build.xml should also be changed to include the permissions.xml in the EAR.

As per Jakarta EE 8 platform specification ApplicationProgrammingInterface (as well as section EE.6.2.2.6 of Java EE 8 platform spec), permissions must be declared at EAR level:
For applications packaged in an .ear file, the declaration of permissions must be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules. Any permissions.xml files within such packaged modules are ignored, regardless of whether a permissions.xml file has been supplied for the .ear file itself.

An example of the EAR correctly including the permissions.xml can be found in securityapi/idstore/customhandler/build.xml

This issue is a clone of jakartaee-tck/issues#132.

The (ant) build.xml fix is already made via pull#138.

@bshannon
Copy link
Contributor

bshannon commented Jan 8, 2020

I agree that the test is buggy and should be excluded for Jakarta EE 8 and fixed for Jakarta EE 9.

Ideally, a negative test would also be added to verify that the permissions.xml is ignored when included in a war file in an ear file.

@kwsutter
Copy link
Contributor

@scottmarlow It looks like this challenge is being accepted and worked on via several other Issues and PRs. Is the work complete? Should we close this Issue? And, if so, which other Issue or PR was used to resolve this TCK problem? Thanks!

@scottmarlow
Copy link
Contributor Author

scottmarlow commented Jan 15, 2020

@kwsutter the challenged test is now excluded on the 8.0 jakartaee-tck branch, however, I think there are still a few steps left to releasing the 8.0.2 TCK.

One such step is publishing the 8.0.2 TCK to jakartaee/platform/8.

While, I already saw passing (GF 5.1) test results for jakartaeetck-8.0.2.zip (Web Profile + Full Platform), Connector, authentication-tck-1.1.1.zip, authorization-tck-1.5.1.zip, security-tck-1.0.1.zip, websocket-tck-1.1.1.zip, I am now working on passing the various certification jobs as well.

The 8.0.2 TCK release also includes an updated client certification (commit#c0b6a + commit#71a44) which is included in the updated standalone TCKs.

Summary of related bundles:

http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/jakartaeetck-8.0.2.zip (sha256sum = adb036ca238a088069c2a58c85f3ee3732a41d703fe7b16e386fdde205a6722e)
https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/jakartaeetck.version:
Git Revision: c457c40af61d307b0dea0e0489fed7ab4c3e8490
Git Branch: (detached
Build Date: Thu Jan 9 23:00:11 UTC 2020
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/authentication-tck-1.1.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/authorization-tck-1.5.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/connectors-tck-1.7.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/security-tck-1.0.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8/promoted/websocket-tck-1.1.1.zip

http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-jakartaeetck-8.0.2.zip (sha256sum = 14a21b617bb646055c2952f1422ec04a71389fb37301e1c2969f6c3700aee965)
Git Revision: c457c40af61d307b0dea0e0489fed7ab4c3e8490
Git Branch: (detached
Build Date: Tue Jan 14 23:46:53 UTC 2020
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-authentication-tck-1.1.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-authorization-tck-1.5.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-connectors-tck-1.7.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-security-tck-1.0.1.zip
http://download.eclipse.org/ee4j/jakartaee-tck/jakartaee8-eftl/promoted/eclipse-websocket-tck-1.1.1.zip

@scottmarlow
Copy link
Contributor Author

scottmarlow commented Jan 15, 2020

To keep the ball rolling on this, I created the jakartaee/specifications/pull request#133.

@scottmarlow
Copy link
Contributor Author

@kwsutter TCK 8.0.2 has now passed the Full Platform + Web Profile tests. jakartaee/specifications/pull/133 is merged and eclipse-jakartaeetck-8.0.2.zip is available, so I think this challenge is now complete.

The challenge should be closed as accepted (as per TCK 1.0 process).

I do have the ability to close this challenge but I do not have "label" permissions, so someone else should label this as accepted. @bshannon can you please label this challenge as accepted?

Thanks,
Scott

@bshannon bshannon added the accepted Accepted certification or challenge request label Jan 20, 2020
@scottmarlow
Copy link
Contributor Author

Thanks @bshannon + @kwsutter + @starksm64 for your help with this challenge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted Accepted certification or challenge request challenge TCK challenge
Projects
None yet
Development

No branches or pull requests

3 participants