It is all about the context classloader, if we let it be the thread creation one then webapp1 can used used then the thread is used in webapp2 with the wrong classloader (but it will work with Managed*ExecutorServices since they override it by task. Now imagine webapp1 is undeployed then you leak it almost completely. Our default avoids it and still works when used as a stack (with Managed*). I don't think the ThreadFactory was intended to be used without Managed* components since it doesn't do anything by itself, all the contextual logic is really in the executor services which are configurable exactly as you want.
If you think it is misleading maybe try to PR an update in our doc?: https://github.com/apache/tomee-site-generator 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 16:23 GMT+02:00 Paul Carter-Brown < [email protected]>: > Thanks Romain, > > I noticed that this worked fine: > > threadFactory.newThread(() -> { > try { > BeanManager beanManager = (BeanManager) new > InitialContext().lookup("java:comp/BeanManager"); > log.warn("SUCCESS IN CREATED THREAD"); > } catch (NamingException ex) { > log.warn("ERROR IN CREATED THREAD: [{}]", ex.toString()); > } > }).run(); > > Interesting that when the threadfactory returns a thread to one's own > executor service then it won't provide the context. > > I tried with ManagedScheduledExecutorService and it works a treat as well. > > Paul > > On 10 September 2017 at 15:43, Romain Manni-Bucau <[email protected]> > wrote: > > > 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 < > > [email protected]>: > > > > > 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 < > > > [email protected]> 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 > > > [email protected] > > > 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> > > > > > > > > > > > > -- > > *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 > [email protected] > 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> > >
