Servlet & CDI Context Propogation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Servlet & CDI Context Propogation

Paul Carter-Brown

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/

BeanManagerBug.zip (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Servlet & CDI Context Propogation

Paul Carter-Brown
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 <[hidden email]> 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
[hidden email]
www.smilecoms.com

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

BeanManagerBug.zip (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Servlet & CDI Context Propogation

Romain Manni-Bucau
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 <
[hidden email]>:

> 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 <
> [hidden email]> 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
> [hidden email]
> 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>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Servlet & CDI Context Propogation

Paul Carter-Brown
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 <[hidden email]>
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 <
> [hidden email]>:
>
> > 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 <
> > [hidden email]> 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
> > [hidden email]
> > 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
[hidden email]
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>

Reply | Threaded
Open this post in threaded view
|

Re: Servlet & CDI Context Propogation

Romain Manni-Bucau
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 <
[hidden email]>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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
> > > [hidden email]
> > > 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
> [hidden email]
> 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>
>
>