Re: [cdi-dev] RequestScope Life Cycle

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 >>>> >: >>>> >>> >>>> >>> 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 >>>> >: >>>> >>>>>>>> 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.