CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Team, Do we have a standard way of propagating CDI contexts (request, session, application, singleton, conversation) and other threadlocal state from a parent thread say servicing a servlet request to its dispatched child runnable using the servlet 3.0 AsyncContext.startAsync or the WorkManager AP

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Hi, i don't know any standard way but what i often saw was to create a kind of "invocation context" to avoid to need anything in the async call. - Romain 2012/6/22 Rohit Kelapure > Team, > > Do we have a standard way of propagating CDI contexts (request, session, > application, singleton, con

Jenkins build is back to stable : OpenWebBeans-trunk #856

See

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Correct. Some code in the container peeks, pushes and pops this JavaEE context before and after the work has been dispatched. On Fri, Jun 22, 2012 at 12:24 PM, Romain Manni-Bucau wrote: > Hi, > > i don't know any standard way but what i often saw was to create a kind of > "invocation context" to

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Hi folks! We are aware that OWB currently doesn't provide this. But all the information is already centrally collected and maintained in the ContextsService. For WAS this will most probably be the WebContextsService. So all you need to know is centrally available there. Also the TheadLocal c

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Team, Does it make sense to propagate the RequestContext ? given that there may be multiple threads that will inherit and share the same RequestContext We will need to manage the destruction of the RequestContext such that only the last one (Parent + child async threads) ends the context. This

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

My understanding of this is that there is still only 1 concurrent Thread. The 'request' will will just get moved over to a new worker, but still max 1 at a time, isn't? But have only read over the spec quickly, will need to dig much deeper... LieGrue, strub >__

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

Servlet 3.0 - Section 2.3.3.3. " When asyncSupported is set to true the application can start asynchronous processing in a separate thread by calling startAsync , passing it a reference to the request and response objects, and then exit from the container on the original thread. This means that th

Re: CDI context propagation for threads spawned asynchronously using servlet 3.0 and javax.resource.spi.work.WorkManager APIs

As far as I understood, not really: "..., and then exit from the container on the original thread." Thus you start the new thread, pass over the context and then exit from the original thread. -> only 1 thread for CDI. It's basically a thread-swapping. IF this gets done atomically (CDI-1.1 wil