[cdi-dev] inheritance of cdi scopes

[Romain Manni-Bucau]

2016-03-06 19:20 GMT+01:00 Reza Rahman <reza_rahman at 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 at 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 at 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 at 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 at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/97c05a92/attachment-0001.html