[
https://issues.jboss.org/browse/WFLY-12098?page=com.atlassian.jira.plugin...
]
Paul Pogonyshev commented on WFLY-12098:
----------------------------------------
Unfortunately, it's not trivial, as it is deeply embedded in our huge application and
further complicated by the fact that the application can run both inside a Web container
(WildFly) and outside it, with limited functionality. In pseudocode I could formulate it
like this:
@WebListener
<whatever>
{
public void contextInitialized (ServletContextEvent event)
{
use (jndiLookup ("java:comp/DefaultManagedScheduledExecutorService"));
}
}
I'm not 100% sure, but it seems when the listener is informed that context is
initialized, not _everything_ is actually initialized yet. In particular, when it tries to
use the JNDI-provided ScheduledExecutorService, the service still uses class loader that
cannot look up application's classes.
At some point later java:comp/DefaultManagedScheduledExecutorService is always replaced
with one that uses correct class loader. However, I'm not sure when exactly this
happens.
Thread context class loader is wrong for ScheduledExecutorService
threads
-------------------------------------------------------------------------
Key: WFLY-12098
URL:
https://issues.jboss.org/browse/WFLY-12098
Project: WildFly
Issue Type: Bug
Components: Concurrency Utilities
Affects Versions: 16.0.0.Final
Reporter: Paul Pogonyshev
Assignee: Ivo Studensky
Priority: Major
Tasks submitted to the standard ScheduledExecutorService (JNDI:
java:comp/DefaultManagedScheduledExecutorService) are executed in threads with class
loader that cannot find application classes. This is a regression in 16.0 compared to 14.0
(haven't tested 15). Tasks submitted to the simple ExecutorService (JNDI:
java:comp/DefaultManagedExecutorService) see the correct class loader.
I.e. if I submit something like
() -> { System.out.println (Thread.currentThread ().getContextClassLoader (); }
to both services (i.e. exactly the same task), I get the following output. For
ScheduledExecutorService (wrong):
ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from
local module loader @275710fc (finder: local module finder @525f1e4e (roots:
[...]/wildfly/modules,[...]/wildfly/modules/system/layers/base))
For ExecutorService (as expected):
ModuleClassLoader for Module "deployment.[...].war" from Service Module
Loader
Plain ExecutorService sees exactly the same class loader as normal threads in which HTTP
request are processed. In version 14.0 this was also true for ScheduledExecutorService.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)