[cdi-dev] Merging JSR-330 into CDI

Werner Keil werner.keil at gmail.com
Sat Mar 19 17:07:17 EDT 2016 

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

More information about the cdi-dev mailing list