Hi Paul, looks like it works as expected.
The default thread factory enforces the container classloader for worker threads to avoid to leak which is fine but *tasks* are intended to set the classloader (differentiate here banalised threads and user tasks). replace your customer scheduled pool by an EE one and you will see how it is supposed to work: @Resource private ManagedScheduledExecutorService scheduledExecutorPoolWithManagedThreadFactory; Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-09-10 12:13 GMT+02:00 Paul Carter-Brown < paul.carter-br...@smilecoms.com>: > I worked out this seems to be an issue in ManagedThreadFactory producing > threads outside of the container context when called from a servlet. See > attached example showing that I can get it to work using my own thread > factory but not ManagedThreadFactory. > > On 9 September 2017 at 15:40, Paul Carter-Brown < > paul.carter-br...@smilecoms.com> wrote: > >> >> Hi, >> >> I have an issue where a servlet Injects a singleton that in turn injects >> a ManagedThreadFactory. >> >> The servlet then uses the singleton that then uses the thread factory to >> create a ScheduledThreadPoolExecutor. >> >> When the ScheduledThreadPoolExecutor is used, the threads don't seem to >> be able to look up things in JNDI such as java:comp/BeanManager. The code >> gets a NamingException that it cannot find comp. >> >> Attached is a test maven project that shows the error. Any idea why this >> is happening. I need to be able to create an executor that has the proper >> app server context. >> >> Using TomEE 7.0.3 >> >> >> Paul >> > > > > -- > > *Paul Carter-Brown* > > *Group Chief Information Officer* > > *Smile Communications Pty (Ltd) * > Smile +234 (0) 702 000 1234 > Mobile +27 (0) 83 4427 179 > Skype PaulC-B > paul.carter-br...@smilecoms.com > www.smilecoms.com > > This email is subject to the disclaimer of Smile Communications at > http://www.smilecoms.com/home/email-disclaimer/ > <http://www.smilecoms.com/disclaimer> > >
