tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Carter-Brown <paul.carter-br...@smilecoms.com>
Subject Re: Servlet & CDI Context Propogation
Date Sun, 10 Sep 2017 14:23:44 GMT
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