[cdi-dev] Merging JSR-330 into CDI

Stephan Knitelius stephan at knitelius.com
Sat Mar 19 17:10:43 EDT 2016 

If it's possible, I am all for it.
On Sa., 19. März 2016 at 22:07, Werner Keil <werner.keil at gmail.com> wrote:

> 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 at lists.jboss.org> wrote:
>
>> Send cdi-dev mailing list submissions to
>>         cdi-dev at 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 at lists.jboss.org
>>
>> You can reach the person managing the list at
>>         cdi-dev-owner at 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 at yahoo.com>
>> Subject: Re: [cdi-dev] Merging JSR-330 into CDI
>> To: cdi-dev at lists.jboss.org
>> Message-ID: <1458416740491-5712817.post at 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 at knitelius.com>
>> Subject: Re: [cdi-dev] Merging JSR-330 into CDI
>> To: Manfred Riem <mnriem at gmail.com>
>> Cc: cdi-dev at lists.jboss.org
>> Message-ID:
>>         <
>> CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg at 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 at 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 at 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 at 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 at 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 at 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 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/20160319/ced89eaa/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 19 Mar 2016 20:35:29 +0000
>> From: Stephan Knitelius <stephan at knitelius.com>
>> Subject: Re: [cdi-dev] @ThreadScoped?
>> To: Mark Struberg <struberg at yahoo.de>, Reza Rahman
>>         <reza_rahman at lycos.com>
>> Cc: cdi-dev <cdi-dev at lists.jboss.org>
>> Message-ID:
>>         <
>> CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA at 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 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.
>>
> -------------- 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 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.
>>
>> End of cdi-dev Digest, Vol 64, Issue 100
>> ****************************************
>>
>
> _______________________________________________
> 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/20160319/9ba9cc30/attachment-0001.html

More information about the cdi-dev mailing list