12:30 p.m.
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 <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
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 <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> _______________________________________________
> 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.