Support inheritance of cdi contexts

[glassfishrobot]

Currently ee concurrency utilities are a nice candidates for reactive pools but not being able to reuse cdi instances kind of make it useless - a simple pool does the same. Being able to say cdi bean instances are inherited would be awesome and would make servlet 3 async feature integrated at ee level in a smooth manner (keep in mind servlet request lifecycle is not cdi one for instance).

Some would say it is dangerous cause not thread safe bit most of these cases are under programmer responsability so it is fine i think

[glassfishrobot]

@glassfishrobot Commented
Reported by rmannibucau

[glassfishrobot]

@glassfishrobot Commented
reza_rahman said:
Please add clarifying examples to this. I can't understand this text let alone act upon it. Even better is contributing a potential fix that can be pulled in from say GitHub into the spec.

[glassfishrobot]

@glassfishrobot Commented
rmannibucau said:
From a servlet chain you have MyBean injected which is resuest scoped. Then in the servlet your start an AsyncContext and launch a task in a ManagedExecutorService. Then you expect very often to have the same MyBean instance which is not the case since request scope is neither started nor inherited.

[glassfishrobot]

@glassfishrobot Commented
reza_rahman said:
This seems pretty legitimate. I'll test it out and double check the spec but it is good for justification of a new revision of the specification.

[glassfishrobot]

@glassfishrobot Commented
reza_rahman said:
Reading the spec it seems obvious to me this case was expected to work along with things like security, JNDI and EJB context. Therefore I am likely to think this is probably an RI bug including perhaps others. I'll file any requisite bugs in the RI and see if they can be fixed.

I'm unlikely to use this as justification for a revision of the spec. I think the text is already clear enough and would only benefit marginally from further clarification.

[glassfishrobot]

@glassfishrobot Commented
rmannibucau said:
And if the main context is destroyed through cdi api what happens? Both cases are broken if unspecified IMO cause a user could rely on both.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA CONCURRENCY_EE_SPEC-39

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/concurrency-ee-spec/issues/39
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @alai8

[njr-11]

MicroProfile Context Propagation and WELD prototyped some work in this space and was able to get some scenarios working. I would like to see how CDI context propagation works standardized within Jakarta EE, but I think the proper place for that to happen is within the CDI specification, which will be better aware of and better equipped to deal with the intricacies of the different scopes and life cycles, as well as able to levy actual requirements against the CDI implementations to make it possible. Is there any way this issue could be transferred over to CDI?