[cdi-dev] RequestScope Life Cycle
Stephan Knitelius
stephan at knitelius.com
Tue Mar 8 10:21:44 EST 2016
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 at gmail.com>
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 at lycos.com>:
>
>> 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 at gmail.com>
>> wrote:
>>
>> 2016-03-08 14:08 GMT+01:00 Reza Rahman <reza_rahman at lycos.com>:
>>
>>> 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 at gmail.com>
>>> 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 at lycos.com>:
>>>
>>>> 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 at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Mon, Mar 7, 2016 at 8:08 PM, Reza Rahman <reza_rahman at lycos.com>
>>>> 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 at lycos.com>
>>>>> 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 at yahoo.de>
>>>>> 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 at 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 at gmail.com> 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 at lycos.com>:
>>>>> >>>> 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 at yahoo.de>
>>>>> 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 at gmail.com>:
>>>>> >>>>>>
>>>>> >>>>>> 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 at lycos.com> 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 at gmail.com> 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/ContextService.html
>>>>> >>>>>>>
>>>>> >>>>>>> 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 at lycos.com> 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 at gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>>
>>>>> >>>>>>>> 2016-03-06 20:59 GMT+01:00 Reza Rahman <reza_rahman at 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 at 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 at gmail.com> wrote:
>>>>> >>>>>>>>> 2016-03-06 20:25 GMT+01:00 Reza Rahman <
>>>>> reza_rahman at 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 at gmail.com> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> 2016-03-06 19:42 GMT+01:00 Reza Rahman <
>>>>> reza_rahman at 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 at gmail.com> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> 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 | Blog | Github | LinkedIn | Tomitriber
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> 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 | Blog | Github | LinkedIn | Tomitriber
>>>>> >>>>>>>>>>>>> _______________________________________________
>>>>> >>>>>>>>>>>>> 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.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> _______________________________________________
>>>>> >>>>>>>>>> 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.
>>>>> >>>>>>>>
>>>>> >>>>>>>> _______________________________________________
>>>>> >>>>>>>> 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.
>>>>> >>>>>> _______________________________________________
>>>>> >>>>>> 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.
>>>>> >>> _______________________________________________
>>>>> >>> 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.
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160308/6c42d213/attachment-0001.html
More information about the cdi-dev
mailing list