-
Notifications
You must be signed in to change notification settings - Fork 591
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
Allow non-EE threads access to java:comp/env names #29484
base: integration
Are you sure you want to change the base?
Allow non-EE threads access to java:comp/env names #29484
Conversation
Signed-off-by: Mike Lothian <[email protected]>
Please code review, @OpenLiberty/reviewer |
Code analysis and actionsDO NOT DELETE THIS COMMENT.
|
This was tested in 3 scenarios: without passing com.ibm.ws.container.service.naming.disableStrictEEJndiProtection at all The first two scenarios gave CWNEN1000E errors and stopped the app from working, the last one allowed the app to continue |
Please code review, @OpenLiberty/reviewer |
#run-libby-bot @ngmr Sorry am I doing this wrong? |
Thanks for this PR. Looks like a good idea. I'm just investigating the implications of this change with colleagues. We would probably add and document a way to configure this in |
Do you have an example of something similar being done that way, I could try and see if I could implement it myself |
@FireBurn It seems like there are a few options about how we would go about this. Could you please open an issue describing the feature as you see it, and include a code snippet of what failed? Also, when you say Java 5, what EE level is that? What type of app at what spec level were you porting to Liberty? (e.g. an EJB 2.0 stateless session bean, in Java EE 1.3) We will review the issue for inclusion. We would eventually need a test to show the lookup that fails now and passes after the changes are made. If you would like to have a go at writing the test, I can direct you to the It might make sense to include it in an existing FAT but that is probably much harder than writing a standalone one. As regards the configuration, it has been suggested that we could just make this behaviour the default so that it doesn't need configuring or enabling at all. We might choose to limit which lookups are allowed since some still do not make sense outside an EE context, and any eventual change should not lose the detailed explanatory message about why not. |
@FireBurn We are specifically interested in which "java:comp" names you would like this to support. Do you really intend to support global resources bound in "java:comp" or application specific resources bound to "java:comp/env"? For example: -> java:comp/UserTransaction is generally a common global resource (except for EJB), so it might make sense to make it available for non-EE threads However: --> java:comp/env/MyDatasource might return different datasources depending on which servlet or EJB is active on the thread. Every Java EE component can define completely different objects for the same name for things in "java:comp/env". Without knowing which component (cmd) is active on a thread, it is likely not possible to determine how to resolve such a lookup. Providing a list of things bound in "java:comp" that you would like to see work would be very helpful. |
Hi, I needed java:comp/UserTransaction for one project and I was attempting to move an old version of FileNet too which was more problematic and required some other ones java:comp/TransactionSynchronizationRegistry - it also wanted java:/TransactionManager but I found another way to do that I've been sidetracked since then |
For related reasons, we have already made |
release bug
label if applicable: https://github.com/OpenLiberty/open-liberty/wiki/Open-Liberty-Conventions).This pull request adds a new boolean com.ibm.ws.container.service.naming.disableStrictEEJndiProtection to allow old apps to use java:comp/env names without getting CWNEN1000E errors
If com.ibm.ws.container.service.naming.disableStrictEEJndiProtection isn't set then then it's disabled, so there are no behavioral changes
This allows an old Java 5 app to run on OpenLiberty with Java 11 without modification