Keeping the few annotations like @Inject as they are should be also in CDI's interest, but as JSR 330 is final there is no EG. Unlike this EG and mailing list with great participation, there has never been too much of an EG even when 330 was active, it was more or less Bob and maybe a few participants in the mailing lists. That activity stopped in 2011, see https://groups.google.com/forum/?hl=de#!forum/atinject-observer, so the EG pretty much died 5 years ago. 

It seems reasonable and natural to do changes or tweaks as part of CDI.

Werner



On Sat, Mar 19, 2016 at 9:35 PM, <cdi-dev-request@lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
        cdi-dev@lists.jboss.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.jboss.org/mailman/listinfo/cdi-dev
or, via email, send a message with subject or body 'help' to
        cdi-dev-request@lists.jboss.org

You can reach the person managing the list at
        cdi-dev-owner@lists.jboss.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdi-dev digest..."


Today's Topics:

   1. Re: Merging JSR-330 into CDI (aalmiray)
   2. Re: Merging JSR-330 into CDI (Stephan Knitelius)
   3. Re: @ThreadScoped? (Stephan Knitelius)


----------------------------------------------------------------------

Message: 1
Date: Sat, 19 Mar 2016 12:45:40 -0700 (MST)
From: aalmiray <aalmiray@yahoo.com>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: cdi-dev@lists.jboss.org
Message-ID: <1458416740491-5712817.post@n5.nabble.com>
Content-Type: text/plain; charset=us-ascii

Precisely my thoughts. Any changes in behavior / binary compatibility in
JSR-330 must be discussed with the JSR-330 EG and stakeholders.

This being said, what would be the real benefit (to both specs) of rolling
JSR-330 as a subspec of CDI?

Cheers,
Andres



--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810p5712817.html
Sent from the CDI Development mailing list mailing list archive at Nabble.com.


------------------------------

Message: 2
Date: Sat, 19 Mar 2016 19:53:13 +0000
From: Stephan Knitelius <stephan@knitelius.com>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: Manfred Riem <mnriem@gmail.com>
Cc: cdi-dev@lists.jboss.org
Message-ID:
        <CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Manfred,

sorry my replay was a bit out of context since, I was referring to Rezas
last mail.

As already discussed yesterday, this could proof difficult. Since there are
other implementations based on JSR-330, most noticeably spring.

What exactly are we looking to gain from integrating JSR-330?

I agree it would be "cleaner", but maybe too much effort for too little
gain.

If we wanted greater control over those parts, maybe it would be better to
move these parts into a separate module for backwards compatibility.
Including new CDI owned annotations alongside the separated JSR-330, as and
where sensible.

Stephan


On Sa., 19. M?rz 2016 at 20:40, Manfred Riem <mnriem@gmail.com> wrote:

> Hi Stephan,
>
> I am suggesting that JSR-330 gets rolled into the CDI spec as a chapter as
> it currently
> stands. Anything beyond that is beyond the scope of the discussion/wish I
> have as that
> would then be decided by the combined EG.
>
> Thanks!
>
> King regards,
> Manfred Riem
>
>
> On Mar 19, 2016, at 2:33 PM, Stephan Knitelius <stephan@knitelius.com>
> wrote:
>
> If I understand you correctly, you are suggesting to move the JSR-330
> annotations into a separate CDI module/profile, thereby semi-deprecating
> these.
>
> This would essentially open up the possibility of replacing @Named, etc...
> with CDI specific annotations.
>
> Certainly an interesting path to explore.
>
> Stephan
>
>
> On Sa., 19. M?rz 2016 at 19:27, Manfred Riem <mnriem@gmail.com> wrote:
>
>> I couldn't agree more ;)
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>> > On Mar 19, 2016, at 10:47 AM, Reza Rahman <reza_rahman@lycos.com>
>> wrote:
>> >
>> > I definitely think it's an idea worth exploring. It will strengthen
>> CDI's hand further. It will be great if some of the confusingly redundant
>> APIs like @Singleton could be deprecated in the process.
>> >
>> > BTW, it is really great to see you active in the community!
>> >
>> >> On Mar 19, 2016, at 10:49 AM, Manfred Riem <mnriem@gmail.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I wrote a little blog entry about a CDI wish I have and in essence it
>> comes
>> >> down to merging JSR-330 into the CDI specification as a sub spec. I
>> realize
>> >> there is history there, but to me it looks like the best course of
>> action.
>> >>
>> >> I had some twitter exchanges about this and some folks are for, some
>> are
>> >> against.
>> >>
>> >> Note I think this is worth exploring as an idea, not something that
>> >> necessarily needs to be in the current JSR, but definitely something
>> that I
>> >> think is worth to do at some point (sooner rather than later in my
>> book).
>> >>
>> >> What do you think?
>> >>
>> >> Thanks!
>> >>
>> >> Kind regards,
>> >> Manfred Riem
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> http://cdi-development-mailing-list.1064426.n5.nabble.com/Merging-JSR-330-into-CDI-tp5712810.html
>> >> Sent from the CDI Development mailing list mailing list archive at
>> Nabble.com <http://nabble.com>.
>> >> _______________________________________________
>> >> 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.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/ced89eaa/attachment-0001.html

------------------------------

Message: 3
Date: Sat, 19 Mar 2016 20:35:29 +0000
From: Stephan Knitelius <stephan@knitelius.com>
Subject: Re: [cdi-dev] @ThreadScoped?
To: Mark Struberg <struberg@yahoo.de>, Reza Rahman
        <reza_rahman@lycos.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160319/1e3adce7/attachment.html

------------------------------

_______________________________________________
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.

End of cdi-dev Digest, Vol 64, Issue 100
****************************************