Re: [cdi-dev] RequestScope Life Cycle

Yes (just making clear it is servlet related asynchronism - ie AsyncContext#complete() is called and listeners are completed - to avoid the ambiguity of @Async, JMS etc.. where request scope is 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> 2016-03-08 16:21 GMT+01:00 Stephan Knitelius <stephan(a)knitelius.com&gt;: > > > So the proposal would be to enable propagation of request scope to > asynchronous threads and keep it alive until all concurrent processes > referencing it are completed? > > On Tue, 8 Mar 2016 at 14:34 Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; > wrote: > >> will try to not hijack this thread and create another one for thread >> scope ;). >> >> >> 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-08 14:30 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >> >>> Your mention of thread local scope is interesting indeed. We had just >>> such a scope in Resin called @ThreadScoped, completely separate from >>> @RequestScoped. As memory serves though even in Resin we basically >>> implemented @RequestScoped as thread local scope. >>> >>> On Mar 8, 2016, at 8:17 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>> wrote: >>> >>> 2016-03-08 14:08 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>> >>>> I never assume anything related to HTTP requests are ever thread safe. >>>> I don't know many folks that would make that assumption either. I think >>>> this consideration is not a significant one. The spec, docs and tutorials >>>> out there are pretty clear about the fact that none of the CDI scopes are >>>> really thread safe in the way EJBs are. >>>> >>>> >>> It is one of the main usage of request scoped in practise. It doesn't >>> come from HTTP side but since it is used this way in several other places >>> (like batch) it is now assumed everywhere. It has even been promoted by >>> several CDI projects so sadly it is to be taken into account now even if I >>> agree it is not the state we should be at today. If changed - servlet >>> 3.0/3.1 broke several things to make the spec cleaner or more explicit so I >>> guess CDI can work on this - it should be made very explicit in the spec >>> and we should study a "thread local scope" replacement to fill the gap and >>> propose a solution to this practise judged abusive. >>> >>> >>>> On Mar 8, 2016, at 7:44 AM, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >>>> wrote: >>>> >>>> In TomEE we restart/stop it around most of hooks including the >>>> runnable passed to start(Runnable) of the AsyncContext but keeping the now >>>> widespread ThreadLocal nature of the @RequestScoped (= not the same as the >>>> startAsync() call sadly). This passes CDI TCK but for the particular >>>> request scope I would be happy to clarify it is actually bound to the >>>> request and just reuse the same instances. In term of side effects it would >>>> breaks the current thread safety users assume (with reason or not) but I >>>> have no real clue if it would really breaks apps or not. >>>> >>>> >>>> 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-08 13:33 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>> >>>>> Let's hope some of the implementors weigh in on this some time soon. >>>>> >>>>> I could write some tests on this but I would have no idea if I would >>>>> have uncovered a bug given the ambiguity of the current spec text. >>>>> >>>>> On Mar 8, 2016, at 3:16 AM, arjan tijms <arjan.tijms(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman <reza_rahman(a)lycos.com&gt; >>>>> wrote: >>>>> >>>>>> Reading over the CDI spec definition for request scoped beans, I am >>>>>> a tad confused. When are request scoped beans being destroyed right now? >>>>>> Are they just bound to the Servlet request thread and destroyed as soon as >>>>>> the service method returns? >>>>> >>>>> >>>>> In case of a Servlet request (request scoped beans are also tied to >>>>> other kinds of "requests"), it's indeed not clear. In practice it looks >>>>> like the moment between the first ServletRequestListener#requestInitialized >>>>> and ServletRequestListener#requestDestroyed. >>>>> >>>>> The exact scope is troublesome for security too, since in most severs >>>>> the request scope (and session scope and application scope) is active when >>>>> a SAM is called (the SAM gets an HttpServletRequest after all), but this is >>>>> not the case in all servers. E.g. in Liberty the RequestScope starts AFTER >>>>> a SAM is called. >>>>> >>>>> Kind regards, >>>>> Arjan Tijms >>>>> >>>>> >>>>> >>>>> >>>>>> In case of asynchronous Servlets, are they kept around until the >>>>>> real HTTP request actually completes the same way the underlying HTTP >>>>>> connection is kept around? Or is that too difficult because it would >>>>>> require integration at a very low level with the Servlet implementation? >>>>>> >>>>>> There's some language around asynchronous completion right now but >>>>>> it's not very clear what actually happens. Does the onComplete, etc >>>>>> asynchronous callback basically create new request scoped instances? >>>>>> >>>>>> > On Mar 7, 2016, at 10:28 AM, Reza Rahman <reza_rahman(a)lycos.com&gt; >>>>>> wrote: >>>>>> > >>>>>> > Even in the most conservative reading of this, the spec is clearly >>>>>> not disallowing it. >>>>>> > >>>>>> >> On Mar 7, 2016, at 10:05 AM, Mark Struberg <struberg(a)yahoo.de&gt; >>>>>> wrote: >>>>>> >> >>>>>> >> The question is whether the spec does allow us to do it. And if >>>>>> other containers consequently do it as well. >>>>>> >> >>>>>> >> If it does then I will implement it in TomEE. >>>>>> >> >>>>>> >> LieGrue, >>>>>> >> strub >>>>>> >> >>>>>> >> >>>>>> >>> Am 07.03.2016 um 14:06 schrieb Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt;: >>>>>> >>> >>>>>> >>> What this is saying is that it is not recommended to use them >>>>>> because of the possible life-cycle mismatch. If they are not supposed to >>>>>> work at all, the specification would have simply stated it won't work. >>>>>> >>> >>>>>> >>> Anyway personally I have no reason to further discuss this. I'm >>>>>> going to try to find a way to get this done for developers sooner rather >>>>>> than later. If TomEE does not want to do it, too bad for developers. >>>>>> >>> >>>>>> >>>> On Mar 7, 2016, at 3:49 AM, Romain Manni-Bucau < >>>>>> rmannibucau(a)gmail.com&gt; wrote: >>>>>> >>>> >>>>>> >>>> " >>>>>> >>>> Tasks that are submitted to a managed instance of >>>>>> ExecutorService may still be running after the lifecycle of the submitting >>>>>> component. Therefore, CDI beans with a scope of @RequestScoped, >>>>>> @SessionScoped, or @ConversationScoped are not recommended to use as tasks >>>>>> as it cannot be guaranteed that the tasks will complete before the CDI >>>>>> context is destroyed. >>>>>> >>>> " >>>>>> >>>> >>>>>> >>>> States that the context is not inherited, is that what you mean? >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> Romain Manni-Bucau >>>>>> >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>>>> >>>> >>>>>> >>>> 2016-03-07 5:57 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com&gt;: >>>>>> >>>> The specification currently references pretty much all the >>>>>> major CDI scopes specifically with the issue of propagation and lifecycle >>>>>> in mind. Please see section 2.3. >>>>>> >>>> >>>>>> >>>>> On Mar 6, 2016, at 11:53 PM, Mark Struberg <struberg(a)yahoo.de&gt; >>>>>> wrote: >>>>>> >>>>> Specifically >>>>>> >>>>> The containers mimic ejb for propagation for a good reason! >>>>>> >>>>> No session e.g. , new TX, etc >>>>>> >>>>> >>>>>> >>>>> Sadly the concurrency utilis only mention @ApplicationScoped, >>>>>> so the Request Context not only doesn't get propagated (which is good), but >>>>>> also doesn't get set up (which is crap). >>>>>> >>>>> >>>>>> >>>>> LieGrue, >>>>>> >>>>> Strub >>>>>> >>>>> >>>>>> >>>>>> Am 06.03.2016 um 23:03 schrieb John D. Ament < >>>>>> john.d.ament(a)gmail.com&gt;: >>>>>> >>>>>> >>>>>> >>>>>> I agree, in a sense, with what you're saying. There's >>>>>> nothing in this spec that says it wouldn't be propagated. However, there's >>>>>> nothing in this spec that states clearly that CDI contexts are propagated. >>>>>> >>>>>> >>>>>> >>>>>> If you look at the RI, the RI only seems to propagate >>>>>> transaction state. Considering the age of the spec, I'm not surprised to >>>>>> see that. The worst part is that right now, outside of the ASF, all other >>>>>> EE7 impls seem to be using the RI for concurrency. >>>>>> >>>>>> >>>>>> >>>>>> I'm fairly certain that from this spec's standpoint, the only >>>>>> thing that's actually propagated is the transaction. >>>>>> >>>>>> >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Mar 6, 2016 at 4:50 PM Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt; wrote: >>>>>> >>>>>> I am re-reading the spec end to end again right now. So far >>>>>> it seems I have remembered everything correctly. >>>>>> >>>>>> >>>>>> >>>>>> You should read over section 2.3. What it is saying is that a >>>>>> container implementing the Java EE concurrency utilities should ensure >>>>>> whatever contextual information is needed for managed components to work >>>>>> correctly should be propagated automatically. For the correct >>>>>> implementation of CDI scopes, this should also mean any currently active >>>>>> scopes. The section you are referring to is basically implying that >>>>>> thinking that it is possible to use these scoped beans in tasks (albeit not >>>>>> reliably since beans could go out of scope before the thread finishes - for >>>>>> example if the request ends). >>>>>> >>>>>> >>>>>> >>>>>> This does not have anything to do with the context service >>>>>> per se. The context service is an SPI of sorts to allow end user developers >>>>>> to do for their own applications what the container does behind the scenes >>>>>> for managed component context propagation. >>>>>> >>>>>> >>>>>> >>>>>> I'll read over the entire spec to see if there is anything to >>>>>> contradict this. If that's not the case what Romain is describing is most >>>>>> likely an implementation specific bug that did not take into account CDI >>>>>> scope propagation. >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 6, 2016, at 4:23 PM, John D. Ament < >>>>>> john.d.ament(a)gmail.com&gt; wrote: >>>>>> >>>>>>> >>>>>> >>>>>>> Reza, >>>>>> >>>>>>> >>>>>> >>>>>>> I read through the concurrency utils spec. Was there a >>>>>> specific section you had in mind? The only references to CDI were near the >>>>>> beginning warning users to not use Request/Session scoped beans as tasks >>>>>> since the outer most context may be destroyed before the work is done. >>>>>> >>>>>>> >>>>>> >>>>>>> I have a feeling what you're referring to is the context >>>>>> service: >>>>>> http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe... >>>>>> >>>>>>> >>>>>> >>>>>>> If that's the case, then basically this should work OOTB >>>>>> right? >>>>>> >>>>>>> >>>>>> >>>>>>> Task task = new MyTask(); >>>>>> >>>>>>> task = contextService.createContextualProxy(task, >>>>>> Task.class); >>>>>> >>>>>>> executor.submit(task); >>>>>> >>>>>>> >>>>>> >>>>>>> // now magically the context should be prop'd? >>>>>> >>>>>>> >>>>>> >>>>>>> Is that about right? >>>>>> >>>>>>> >>>>>> >>>>>>> John >>>>>> >>>>>>> >>>>>> >>>>>>> On Sun, Mar 6, 2016 at 3:30 PM Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt; wrote: >>>>>> >>>>>>> Have you actually looked at the EE concurrency spec text in >>>>>> detail? What does it say about managed component context propagation? >>>>>> >>>>>>> >>>>>> >>>>>>> Without actually doing that further discussing this is just >>>>>> taking shots in the dark. As an implementer it should not surprise you that >>>>>> this might simply be a bug because the person implementing the concurrency >>>>>> utilities for the EE runtime was not told about what to copy over into the >>>>>> new thread for CDI to work correctly. >>>>>> >>>>>>> >>>>>> >>>>>>>> On Mar 6, 2016, at 3:06 PM, Romain Manni-Bucau < >>>>>> rmannibucau(a)gmail.com&gt; wrote: >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>>> 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&gt; 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&gt; wrote: >>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>>>> 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&gt; wrote: >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>>>>> 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&gt; wrote: >>>>>> >>>>>>>>>>> >>>>>> >>>>>>>>>>> 2016-03-06 19:20 GMT+01:00 Reza Rahman < >>>>>> reza_rahman(a)lycos.com&gt;: >>>>>> >>>>>>>>>>> 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&gt; 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&gt;: >>>>>> >>>>>>>>>>>> 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&gt; 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. >>>>>> >>>>>>>>>> >>>>>> >>>>>>>>>> _______________________________________________ >>>>>> >>>>>>>>>> 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. >>>>>> >>>>>>>> >>>>>> >>>>>>>> _______________________________________________ >>>>>> >>>>>>>> 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. >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> 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. >>>>>> >>> _______________________________________________ >>>>>> >>> 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. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. > >