You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Paul Carter-Brown <pa...@smilecoms.com> on 2017/09/09 13:40:41 UTC

Servlet & CDI Context Propogation

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

-- 


This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ <http://www.smilecoms.com/disclaimer>


Re: Servlet & CDI Context Propogation

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@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>
>
>

Re: Servlet & CDI Context Propogation

Posted by Paul Carter-Brown <pa...@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 <rm...@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>


Re: Servlet & CDI Context Propogation

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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>
>
>

Re: Servlet & CDI Context Propogation

Posted by Paul Carter-Brown <pa...@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>