<p dir="ltr"><br>
Le 20 mars 2016 21:07, "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> a écrit :<br>
><br>
> See Bean#getScope() and BeanManager#getContext()<br>
><br>
> Just uses Class and no Annotation instance.<br>
></p>
<p dir="ltr">That's ok I think. Since 1.2 you can get meta from any bean and find it if needee but i most of cases the context will see the bean and will not need it.</p>
<p dir="ltr">Would also break the Annotated contravt if true.</p>
<p dir="ltr">> Lgm<br>
><br>
><br>
> --------------------------------------------<br>
> On Sun, 20/3/16, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br>
><br>
> Subject: Re: [cdi-dev] @ThreadScoped?<br>
> To: "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
> Cc: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>, "Reza Rahman" <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>><br>
> Date: Sunday, 20 March, 2016, 20:47<br>
><br>
> Le 20 mars 2016 20:40,<br>
> "Mark Struberg" <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
> a écrit :<br>
> ><br>
> > A scope<br>
> annotation cannot have a flag.<br>
> ><br>
><br>
> Why? Technically it can<br>
><br>
> > LieGrue,<br>
> > strub<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> On Sunday, 20 March 2016, 20:25, Reza Rahman <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>><br>
> wrote:<br>
> ><br>
> ><br>
> > ><br>
> > ><br>
> > >As discussed<br>
> elsewhere in this EG, even in the most pessimistic<br>
> reading<br>
> of the current spec, all that would<br>
> be needed is a flag on the existing<br>
> annotation. It's not out of the question at<br>
> all.<br>
> > ><br>
> > >On<br>
> Mar 20, 2016, at 1:36 PM, Manfred Riem <<a href="mailto:mnriem@gmail.com">mnriem@gmail.com</a>><br>
> wrote:<br>
> > ><br>
> ><br>
> ><br>
> > >Why is changing @RequestScoped<br>
> out of the question?<br>
> > >><br>
> > >><br>
> > >>From<br>
> my perspective when an AsyncContext is started the request<br>
> is<br>
> still there.<br>
> ><br>
> >><br>
> > >><br>
> ><br>
> >>It is just being served by a different thread.<br>
> > >><br>
> > >><br>
> > >>Certainly there is a need to work<br>
> with the Servlet EG to figure out how<br>
> to<br>
> transfer “ownership” to the AsyncContext.<br>
> > >><br>
> > >><br>
> > >>Anyway my 2 cents<br>
> > >><br>
> > >><br>
> > >>Thanks!<br>
> ><br>
> >><br>
> > >><br>
> ><br>
> >>Kind regards,<br>
> > >>Manfred<br>
> Riem<br>
> > >><br>
> ><br>
> >><br>
> > >>On Mar 19, 2016, at<br>
> 3:35 PM, Stephan Knitelius <<a href="mailto:stephan@knitelius.com">stephan@knitelius.com</a>><br>
> wrote:<br>
> > >>><br>
> > >>>I would certainly agree with<br>
> the assertion that in general it's not<br>
> advisable to execute a request with multiple<br>
> threads and that usually<br>
> single threaded<br>
> execution is sufficient.<br>
> ><br>
> >>><br>
> > >>>However I<br>
> don't think ignoring it is an option. Concurrent<br>
> operations<br>
> can be launched even from CDI<br>
> beans. Yet we don't properly support context<br>
> propagation nor a context spanning all threads<br>
> launched from a request.<br>
> ><br>
> >>><br>
> > >>>I know that<br>
> changing @requestScoped is probably out of the question,<br>
> but at least we should consider adding a new<br>
> context spanning all threads<br>
> and defining a<br>
> logical solution for context propagation that can be<br>
> explained to the end user.<br>
> ><br>
> >>><br>
> > >>><br>
> > >>><br>
> ><br>
> >>><br>
> > >>>On Fr., 11.<br>
> März 2016 at 17:17, Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
> wrote:<br>
> > >>><br>
> > >>>Yes, but certain things in EE<br>
> are assumed to be handled on a single<br>
> thread. And if you run on a servr then this is<br>
> really not a blocker most<br>
> times. If I get<br>
> many paralllel requests hitting my box then I do not need<br>
> async handling _that_ often. The whole overhead<br>
> for setting up the new<br>
> thread, etc often<br>
> heavily exceeds the benefits.<br>
> ><br>
> >>>>So I would not put too much energy into<br>
> it…<br>
> > >>>><br>
> > >>>>LieGrue,<br>
> > >>>>strub<br>
> ><br>
> >>>><br>
> > >>>>><br>
> Am 11.03.2016 um 15:44 schrieb Reza Rahman <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>>:<br>
> > >>>>><br>
> ><br>
> >>>>> This is essentially in keeping with the<br>
> minimalist nature of the EE<br>
> concurrency JSR.<br>
> I believe most of it is left to vendors to do the right<br>
> thing for users. May be a good idea is this<br>
> language can be tightened up.<br>
> ><br>
> >>>>><br>
> ><br>
> >>>>>> On Mar 11, 2016, at 6:01 AM, Mark<br>
> Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
> wrote:<br>
> ><br>
> >>>>>> E<br>
> ><br>
> >>>>>> From the servlet spec:<br>
> > >>>>>><br>
> > >>>>>> „Java<br>
> Enterprise Edition features such as Section 15.2.2,<br>
> “Web<br>
> Application Environment” on page<br>
> 15-174 and Section 15.3.1, “Propagation of<br>
> Security Identity in EJBTM Calls” on page<br>
> 15-176 are available only to<br>
> threads<br>
> executing the initial request or when the request is<br>
> dispatched to<br>
> the container via the<br>
> AsyncContext.dispatch method. Java Enterprise Edition<br>
> features may be available to other threads<br>
> operating directly on the<br>
> response object<br>
> via the AsyncContext.start(Runnable) method.“<br>
> > >>>>>><br>
> > >>>>>> check<br>
> „available only to threads executing the initial<br>
> request“<br>
> > >>>>>><br>
> > >>>>>> Also if you look<br>
> at the servlet AsyncContext then all the wording<br>
> is written as MAY and not as MUST.<br>
> > >>>>>><br>
> > >>>>>> LieGrue,<br>
> > >>>>>> strub<br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>>> Am 10.03.2016<br>
> um 19:52 schrieb Romain Manni-Bucau <<br>
> <a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
> > >>>>>>><br>
> > >>>>>>> Hi Mark,<br>
> > >>>>>>><br>
> > >>>>>>> think 2.3.3.4<br>
> states the opposite.<br>
> ><br>
> >>>>>>><br>
> ><br>
> >>>>>>><br>
> ><br>
> >>>>>>> Romain Manni-Bucau<br>
> > >>>>>>> @rmannibucau<br>
> | Blog | Github | LinkedIn | Tomitriber<br>
> > >>>>>>><br>
> > >>>>>>> 2016-03-10<br>
> 19:43 GMT+01:00 Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>:<br>
> > >>>>>>> Back from<br>
> JavaLand conference, so sorry for not kicking in<br>
> earlier.<br>
> ><br>
> >>>>>>><br>
> ><br>
> >>>>>>> I not quite get the<br>
> argumentation chain. It’s that all triggered<br>
> by async servlet requests? And isn’t the<br>
> servlet spec also saying that all<br>
> the<br>
> request param etc may max be assigned to a single thread AT<br>
> A TIME!<br>
> > >>>>>>><br>
> > >>>>>>> Means that it<br>
> might not be on multiple threads in parallel, but<br>
> the data is allowed to get moved from one<br>
> thread to another (disapearing<br>
> from the<br>
> first one), right?<br>
> ><br>
> >>>>>>> Would really need to dig into<br>
> the wording of the async servlets<br>
> spec<br>
> again, maybe has this in the back of his head?<br>
> > >>>>>>><br>
> > >>>>>>> LieGrue,<br>
> > >>>>>>> strub<br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>><br>
> > >>>>>>>> Am<br>
> 08.03.2016 um 14:43 schrieb Romain Manni-Bucau <<br>
> <a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>:<br>
> > >>>>>>>><br>
> > >>>>>>>> Hi<br>
> guys,<br>
> ><br>
> >>>>>>>><br>
> ><br>
> >>>>>>>> following request scope<br>
> thread and to center the discussion on<br>
> the<br>
> thread safety part: do we work on this?<br>
> ><br>
> >>>>>>>><br>
> ><br>
> >>>>>>>> Background: @RequestScoped<br>
> is often used as a ThreadLocal<br>
> instance<br>
> solution. A lot of SE or Batch implementations rely on it<br>
> from<br>
> what I saw as well as async<br>
> implementations reusing existing business logic<br>
> with this thread safety constraint.<br>
> > >>>>>>>><br>
> > >>>>>>>> Proposal:<br>
> providing a @ThreadScoped implementation is cheap for<br>
> CDI and implemenation and would avoid the<br>
> headache we can have with<br>
> @RequestScoped.<br>
> Will also remove the quite dark side of the spec<br>
> regarding<br>
> servlet request and request scope<br>
> since now we would have a more natural<br>
> solution for all of these situation so<br>
> @RequestScoped goals wouldn't<br>
> collide as<br>
> much.<br>
> ><br>
> >>>>>>>><br>
> ><br>
> >>>>>>>> Questions:<br>
> > >>>>>>>> - is it<br>
> automatically started as request scoped is (JMS, @Async,<br>
> ...)? Alternative could be some configuration<br>
> in beans.xml (merged accross<br>
> the app):<br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> <beans><br>
> ><br>
> >>>>>>>> <scopes><br>
> ><br>
> >>>>>>>> <thread><br>
> > >>>>>>>> <br>
> <active>JMS</active><br>
> > >>>>>>>> <br>
> <active>ASYNCHONOUS</active><br>
> ><br>
> >>>>>>>> </thread><br>
> > >>>>>>>><br>
> </scopes><br>
> ><br>
> >>>>>>>> </beans><br>
> > >>>>>>>><br>
> > >>>>>>>> -<br>
> start/stop API (this is typically an API the user should<br>
> be<br>
> able to control for its own threads)<br>
> > >>>>>>>> - CDI<br>
> 2.*0*?<br>
> ><br>
> >>>>>>>><br>
> ><br>
> >>>>>>>> wdyt?<br>
> ><br>
> >>>>>>>><br>
> ><br>
> >>>>>>>> Romain Manni-Bucau<br>
> > >>>>>>>><br>
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber<br>
> > >>>>>>>><br>
> _______________________________________________<br>
> > >>>>>>>> cdi-dev<br>
> mailing list<br>
> ><br>
> >>>>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > >>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >>>>>>>><br>
> > >>>>>>>> Note that<br>
> for all code provided on this list, the provider<br>
> licenses the code under the Apache License,<br>
> Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> ><br>
> >>>>>>><br>
> ><br>
> >>>>>>><br>
> ><br>
> >>>>>><br>
> ><br>
> >>>>>><br>
> ><br>
> >>>>>><br>
> _______________________________________________<br>
> > >>>>>> cdi-dev mailing<br>
> list<br>
> > >>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > >>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >>>>>><br>
> > >>>>>> Note that for all<br>
> code provided on this list, the provider<br>
> licenses the code under the Apache License,<br>
> Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> > >>>>><br>
> > >>>>><br>
> _______________________________________________<br>
> > >>>>> cdi-dev mailing<br>
> list<br>
> > >>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > >>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >>>>><br>
> ><br>
> >>>>> Note that for all code provided on this<br>
> list, the provider licenses<br>
> the code under<br>
> the Apache License, Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> > >>>><br>
> > >>>><br>
> ><br>
> >>>>_______________________________________________<br>
> > >>>>cdi-dev mailing list<br>
> > >>>><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > >>>><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >>>><br>
> ><br>
> >>>>Note that for all code provided on this<br>
> list, the provider licenses<br>
> the code under<br>
> the Apache License, Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> ><br>
> _______________________________________________<br>
> > >>>cdi-dev mailing list<br>
> > >>><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > >>><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > >>><br>
> ><br>
> >>>Note that for all code provided on this list,<br>
> the provider licenses<br>
> the code under the<br>
> Apache License, Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> > >><br>
> ><br>
> >_______________________________________________<br>
> > >cdi-dev mailing list<br>
> > ><a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > ><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> > ><br>
> > >Note that<br>
> for all code provided on this list, the provider licenses<br>
> the<br>
> code under the Apache License, Version 2<br>
> (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> _______________________________________________<br>
> > cdi-dev mailing list<br>
> ><br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> ><br>
> > Note that for all<br>
> code provided on this list, the provider licenses the<br>
> code under the Apache License, Version 2 (<br>
> <a href="http://www.apache.org/licenses/LICENSE-2.0.html">http://www.apache.org/licenses/LICENSE-2.0.html</a>).<br>
> For all other ideas<br>
> provided on this list,<br>
> the provider waives all patent and other<br>
> intellectual property rights inherent in such<br>
> information.<br>
</p>