[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Behrooz Nobakht  changed:

   What|Removed |Added

 Status|NEEDINFO|NEW

--- Comment #3 from Behrooz Nobakht  ---
Extracting a minimal reproducible example is quite difficult for me. I will
explain the current situation as is.

Tomcat is used with a custom server.xml:























Please note the definition of `Resource` in above.

When accessing one of the HTTP endpoints on the app, a business objects wants
for the first time to gain access to the JNDI resource
`java:env/comp/UserTransaction`. 

Because there's no custom definition of NamingContext provider API, the default
is picked by javax.naming.InitialContext. 

This is L313 of javax.naming.InitialContext in Java 1.8.0_172:

defaultInitCtx = NamingManager.getInitialContext(myProps);

`myProps` is filled by Catalina bootstrap to point to Apache Naming
implementation.

Going further down the stack, you will reach
com.sun.naming.internal.VersionHelper12 at L61:

return loadClass(className, getContextClassLoader());

The fix for ForkJoinWorkerThreadFactory means that there will be no context
class loader, which means it will be "system" class loader and eventually leads
to ClassNotFoundException.


Hope this clarifies further the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

DBCP2 in Tomcat

[Rémy Maucherat]

Hi,

In Tomcat, DBCP2 is missing the XA portion (all contained in a single
"managed" package). So at work I now got some people asking about that
removal, and that's always a bit annoying as they have to go to a separate
vanilla DBCP2 to get the functionality. Annoying sometimes.

So it would be possible to add the classes in Tomcat (including the
javax.transaction to build, as that's the Tomcat way to deal with that),
even though the user would need to add its own transaction manager to do
anything with it.

Should I now add it (only in 9/trunk) or instead leave things the way they
are ? Both work to be honest, it's just that I've been bitten by the "we
only ship 3/4 of DBCP and I didn't know it" bug.

Rémy

[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Remy Maucherat  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Remy Maucherat  ---
Ok so the revision is here: http://svn.apache.org/viewvc?rev=1778061=rev
It is supposedly no longer needed on Java 9+, so a subsequent revision could be
made to avoid it in that case. Note that you also have a setting on
JreMemoryLeakPreventionListener to disable it.

I don't get how this, by itself, then causes the naming context factory
failure. Please explain how to reproduce it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org