[
https://issues.jboss.org/browse/WFLY-12098?page=com.atlassian.jira.plugin...
]
Ivo Studensky commented on WFLY-12098:
--------------------------------------
[~doublep_] Can I ask you for a reproducer of this? The ScheduledExecutorService should
have the correct class loader set. It is covered by testcases on our side.
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)