Please code review, @OpenLiberty/reviewer

Code analysis and actions

• 1 product code files were changed.
• Please describe in a separate comment how you tested your changes.

This was tested in 3 scenarios:

without passing com.ibm.ws.container.service.naming.disableStrictEEJndiProtection at all
with -Dcom.ibm.ws.container.service.naming.disableStrictEEJndiProtection=false
with -Dcom.ibm.ws.container.service.naming.disableStrictEEJndiProtection=true

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 server.xml rather than use a system property.

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 server.xml rather than use a system property.

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 build.example_fat project as an example of a test project to copy.

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 UserTransaction globally available from jndi via new InitialContext().lookup("jta/usertransaction").
See issue #28647 for details.
Would that work for you?