5:20 a.m.
Hi,
If you feel that CDI TCK breaks something then raise an issue please.
Tom
----- Original Message -----
From: "Romain Manni-Bucau" <rmannibucau(a)gmail.com>
To: "Reza Rahman" <reza_rahman(a)lycos.com>
Cc: cdi-dev(a)lists.jboss.org
Sent: Sunday, March 6, 2016 9:06:59 PM
Subject: Re: [cdi-dev] inheritance of cdi scopes
2016-03-06 20:59 GMT+01:00 Reza Rahman < reza_rahman(a)lycos.com > :
As far as I know this is precisely the sort of thing that the EE concurrency spec is
intended for. It is supposed to copy over everything from the underlying thread local
context into the new thread for all EE managed components to function. Since CDI beans are
also EE container managed, it also applies to CDI beans as well. The EE vendor is supposed
to make sure this works properly.
I don't think the concurrency utilities specifically lists APIs for which thread
context propagation should work. If this doesn't work in a specific implementation
it's most likely because they didn't take CDI into account in their own EE
concurrency implementation.
That's what I wanted/would like. CDI TCK breaks it quite easily and @RequestScoped
which is *used* today is sadly a @ThreadLocalScoped badly named. So to solve it we would
need another scope as I mentionned several times on this list 100% matching servlet
instances lifecycles (on a pure CDI side we have the same issue for sessions which are
recycled during a request, the session scope is corrupted *by spec* in term of user
behavior).
On Mar 6, 2016, at 2:45 PM, John D. Ament < john.d.ament(a)gmail.com > wrote:
The section of the spec you link to makes no references to threads. 6.3 makes some notes
about normal scopes and threads, and specifically says that a context is bound to one or
more threads.
I think what's happened is that over the years, people have simply bound HTTP Request
== single thread, but when async processing was introduced no one thought to clarify that
the spawning of a child thread from the original HTTP request retains the parent's
context.
This is another requested feature, but looks more like a bug or gap in the spec.
John
On Sun, Mar 6, 2016 at 2:37 PM Romain Manni-Bucau < rmannibucau(a)gmail.com > wrote:
2016-03-06 20:25 GMT+01:00 Reza Rahman < reza_rahman(a)lycos.com > :
Let's see. I suspect the specification text for EE concurrency is generic enough for
implementations to also be able to cover CDI scopes or any other Java EE API context
propagation needs. This means the issue needs to be solved at the individual
implementation level. Changing anything in the spec is probably just unnecessary ceremony
in this case.
Then 1. concurrency- utility can't be reliable for "EE" users, 2. CDI still
prevent it to work since it would violate the spec to propagate it while request scope is
bound to another thread ( http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context
handles async listener but not the main AsyncContext part).
On Mar 6, 2016, at 2:15 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com > wrote:
2016-03-06 19:42 GMT+01:00 Reza Rahman < reza_rahman(a)lycos.com > :
This frankly surprises me. I'll check the specification text. This might indeed just
be an implementation bug. The EE concurrency utilities are supposed to be copying all
relevant context. If this is an issue than it has to be that it is not copying enough of
the HTTP request context for CDI to work.
The issue is not technical since I got it working but needed to reverse. From my
understanding ee concurrency utilities was done in a time CDI was not there so it just
ignored it somehow and it hasnt been updated when integrated to the spec. Now with the
wording of the CDI - and TCK - it is impossible to make it working since request scope is
bound the thre request thread - and not the request. Side note: same applies to session
scope and conversation.
Surely the Red Hat folks can quickly shed some light here since they implement essentially
this whole stack?
On Mar 6, 2016, at 1:30 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com > wrote:
2016-03-06 19:20 GMT+01:00 Reza Rahman < reza_rahman(a)lycos.com > :
Can you kindly try to make the example a bit simpler? It's important to make the case
for how likely this is supposed to occur in most business applications.
Also, other than making sure that the executor service is propagating thread local request
contexts correctly what other solution are you proposing? Did you check the specification?
How sure are you that this isn't simply an implementation bug?
As far as I know the executor service is supposed to be preserving all relevant parts of
the EE context?
Not in concurrency-utilities for EE at least. That was the first impl I did then Mark
pointed out it was violating CDI spec and request scope definition. There is a kind of
contracdiction there cause concurrency-utilities doesn't integrate with CDI at all but
we can also see it the opposite way: CDI doesn't provide any way to propagate a
context in another thread. Both point of view are valid so we need to see where we tackle
it.
On Mar 6, 2016, at 12:35 PM, Romain Manni-Bucau < rmannibucau(a)gmail.com > wrote:
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(a)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(a)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(a)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(a)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(a)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.