Le 20 mars 2016 21:07, "Mark Struberg" <struberg@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@gmail.com> wrote:
>
>  Subject: Re: [cdi-dev] @ThreadScoped?
>  To: "Mark Struberg" <struberg@yahoo.de>
>  Cc: cdi-dev@lists.jboss.org, "Reza Rahman" <reza_rahman@lycos.com>
>  Date: Sunday, 20 March, 2016, 20:47
>
>  Le 20 mars 2016 20:40,
>  "Mark Struberg" <struberg@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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.