[cdi-dev] RequestScope Life Cycle
Antoine Sabot-Durand
antoine at sabot-durand.net
Tue Mar 8 11:55:51 EST 2016
I'm not a big fan of this option: not very clear for end user and
introducing a member in exisitng scope annotaion could bring issues. But
please Romain, feel free to fill a ticket a propose something. The main
problem is more the implementation than the API anyway ;).
Antoine
Le mar. 8 mars 2016 à 17:46, Romain Manni-Bucau <rmannibucau at gmail.com> a
écrit :
> is a flag an option? @RequestScoped(inherited = true)
>
>
> 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 17:44 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>
> :
>
>> As we already discussed during async event debate, we really should think
>> about propagating normal scopes to be align on servlet and prepare CDI for
>> reactive programming.
>> We can't break the way existing built-in normal scopes work today (no
>> propagating and ApplicationScoped being shared) but nothing prevent us to
>> introduce new normal scope supporting propagation (@AsyncRequestScoped for
>> instance).
>>
>> Le mar. 8 mars 2016 à 17:38, Romain Manni-Bucau <rmannibucau at gmail.com>
>> a écrit :
>>
>>> For Servlet 3.1 I don't have much doubts on the beneficial side but for
>>> the other cases I'm sure it would break a lot of code written on EE 6 or 7
>>> where @RequestScoped beans have been used as thread local intances. So
>>> typically a HTTP request or JMS message calling an @Asynchronous EJB would
>>> break apps if you decide to propagate the context now. Same for websockets
>>> - which still don't have a scope - but in a lighter way since it is not yet
>>> mainstream.
>>>
>>> Even if such change makes sense it shouldn't be done
>>> without widely asking users to acknowledge it. Doing it is much more work
>>> and wider than the original mail so maybe it should be discussed in two
>>> steps.
>>>
>>>
>>> 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 17:00 GMT+01:00 Paul Benedict <pbenedict at apache.org>:
>>>
>>>> I agree with Stephan. Since the introduction of asynchronous processing
>>>> in Servlet 3.1, the 1:1 assumption between request-thread has been removed.
>>>> A "request" should not be synonymous with a single thread anymore; but the
>>>> entire request operation.
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Tue, Mar 8, 2016 at 9:55 AM, Stephan Knitelius <
>>>> stephan at knitelius.com> wrote:
>>>>
>>>>> I am not sure I am following you 100%.
>>>>>
>>>>> For me a request is anything which comes into the context of the
>>>>> application. No matter if it comes in via Servlet, WebSockets, JMS, Remote
>>>>> EJB, etc...
>>>>>
>>>>> The request scope should be propagated to all asynchronous operations
>>>>> launched within that call, terminating it when all request associated
>>>>> asynchronous operations are completed.
>>>>>
>>>>> Knitti
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 8 Mar 2016 at 16:48 Romain Manni-Bucau <rmannibucau at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 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 at knitelius.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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/5fab1f40/attachment-0001.html
More information about the cdi-dev
mailing list