does https://gist.github.com/rmannibucau/d55fce47b001185dca3e help?

Idea is to give an API to make:

public void complete() {
try {
asyncContext.complete();
} finally {
auditContext.end();
}
}

working without hacky and almost impossible context pushing (cause of injections nature you are not supposed to know what to push in the context when going async).



Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber

2016-03-06 16:40 GMT+01:00 Reza Rahman <reza_rahman@lycos.com>:
Can you kindly share an annotated code example of the proposed solution so we can all follow and discuss this?

On Mar 6, 2016, at 9:31 AM, Romain Manni-Bucau <rmannibucau@gmail.com> wroteshar:

Hi guys,

spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is.

Sample:
In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally.

Bonus:
One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat.

Question:
Would CDI handle it in 2.0?

Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now.


Romain Manni-Bucau
@rmannibucau |  Blog | Github | LinkedIn | Tomitriber
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.