tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Servlet & CDI Context Propogation
Date Sun, 10 Sep 2017 14:46:47 GMT
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 <
paul.carter-brown@smilecoms.com>:

> 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 <rmannibucau@gmail.com>
> 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 <
> > paul.carter-brown@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-brown@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-brown@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>
> > >
> > >
> >
>
>
>
> --
>
> *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-brown@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>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message