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