10:07 p.m.
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(a)lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
cdi-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
cdi-dev-owner(a)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(a)yahoo.com>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: cdi-dev(a)lists.jboss.org
Message-ID: <1458416740491-5712817.post(a)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...
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(a)knitelius.com>
Subject: Re: [cdi-dev] Merging JSR-330 into CDI
To: Manfred Riem <mnriem(a)gmail.com>
Cc: cdi-dev(a)lists.jboss.org
Message-ID:
<
CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg(a)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(a)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(a)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(a)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(a)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(a)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...
>> >> Sent from the CDI Development mailing list mailing list archive at
>> Nabble.com <http://nabble.com>;.
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >> cdi-dev(a)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(a)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(a)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/at...
------------------------------
Message: 3
Date: Sat, 19 Mar 2016 20:35:29 +0000
From: Stephan Knitelius <stephan(a)knitelius.com>
Subject: Re: [cdi-dev] @ThreadScoped?
To: Mark Struberg <struberg(a)yahoo.de>, Reza Rahman
<reza_rahman(a)lycos.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<
CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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/at...
------------------------------
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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
****************************************
10:10 p.m.
New subject: Merging JSR-330 into CDI
If it's possible, I am all for it.
On Sa., 19. März 2016 at 22:07, Werner Keil <werner.keil(a)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(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)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(a)yahoo.com>
> Subject: Re: [cdi-dev] Merging JSR-330 into CDI
> To: cdi-dev(a)lists.jboss.org
> Message-ID: <1458416740491-5712817.post(a)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...
> 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(a)knitelius.com>
> Subject: Re: [cdi-dev] Merging JSR-330 into CDI
> To: Manfred Riem <mnriem(a)gmail.com>
> Cc: cdi-dev(a)lists.jboss.org
> Message-ID:
> <
> CAGMB8Y1pe60oOc35uA19MpmeEjUMLZGn39vPTofxS24_8gcnyg(a)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(a)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(a)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(a)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(a)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(a)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...
> >> >> Sent from the CDI Development mailing list mailing list archive at
>
>> Nabble.com <http://nabble.com>;.
> >> >> _______________________________________________
> >> >> cdi-dev mailing list
> >> >> cdi-dev(a)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(a)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(a)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/at...
>
> ------------------------------
>
> Message: 3
> Date: Sat, 19 Mar 2016 20:35:29 +0000
> From: Stephan Knitelius <stephan(a)knitelius.com>
> Subject: Re: [cdi-dev] @ThreadScoped?
> To: Mark Struberg <struberg(a)yahoo.de>, Reza Rahman
> <reza_rahman(a)lycos.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAGMB8Y0_19L6-cZZS7AEVh+ye0bx6+S9tqNV35ixaWD3eT5uoA(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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(a)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.
8:34 a.m.
New subject: Merging JSR-330 into CDI
What are the benefits?
I mean serious, what does CDI gain?
I can at least tell you what it hurts:
TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to change. I
like to see CODE to show possible benefits. Before that I don't waste any more energy,
and you should neither.
long version:
1.) A lot specs are currently worded to only need JSR-330 for users. That way they run
fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is wrong with that?
2.) What changes do you need in atinject? We had a few ideas and sent them to the JSR-330
EG a year ago. We had good discussions but none of our wishes was worked out because WE
failed to make final suggestions!
The atinject EG (Bob, Jürgen) has been responsive. At least MUCH more responsive than
other EG leaders these days... So I fail to see why the atinject EG is 'inactive since
5 years'. That's just wrong information.
3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden
to split a java package into multiple specs.
4.) We also cannot just amend the annotations and take them 'over'. That would
require the EC to officially move the maintenance of atinject to the CDI EG. Or even
requires a handover from the atinject EG. I'm not sure about that
5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great. But then
again: Show me an example what we would gain from it! Stop trashtalking but show CODE
instead!
6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is busy as hell
to get this done. You might add this to a CDI-3.0 wishlist, but that's it for now
imo.
7.) The JSR-330 spec had an important political role back then. I know most people
don't know that, but it's still great to have this little peace which managed to
make peace. Not peace between Spring and EE as many people believe, back then it was more
that it brought mainly peace between CDI and most of the rest of JavaEE EGs! Remember that
we haven't been allowed to target Java SE in CDI-1.0? Remember that we were force to
have the 'for Java Enterprise' in the spec name? Remember that we had big battles
with EJB? No, then just take it as granted and let it rest...
LieGrue,
strub
9:14 a.m.
New subject: Merging JSR-330 into CDI
I'll give you an example:
Currently many specs refer to atinject but also to CDI, because they need to use
@Nonbinding (e.g. in Qualifiers).
Thus Antoine and I asked the atinject EG whether they might introduce a @Nonbinding
annotation. During that I learned that annotations not available on the classpath will
_not_ blow up but simply don't appear at Runtime in Class#getAnnotations() etc.
Means if you don't have the cdi-api.jar on your classpath the @Nonbinding annotation
just doesn't show up at Runtime.
Since Spring and Guice seems to not need this feature it's all fine from a CDI pov.
Imagine what it would have meant to us if we would have got a second @Nonbinding in the
javax.inject packgae: we would have to duplicate all the code which currently handling
@Nonbinding.
And that was actually the most important requirement the CDI EG came up for atinject in
the last 7 years.
Thus before we continue any discussions and further rouse people I like to see clear ideas
WHAT you like to get changed in atinject.
LieGrue,
strub
On Sunday, 20 March 2016, 8:35, Mark Struberg
<struberg(a)yahoo.de> wrote:
> What are the benefits?
I mean serious, what does CDI gain?
I can at least tell you what it hurts:
TL/DR: Instead of claiming HOW cool it would be please show WHAT you like to
change. I like to see CODE to show possible benefits. Before that I don't
waste any more energy, and you should neither.
long version:
1.) A lot specs are currently worded to only need JSR-330 for users. That way
they run fine with CDI, Spring, etc. E.g. JBatch, Bean-Validation, etc. What is
wrong with that?
2.) What changes do you need in atinject? We had a few ideas and sent them to
the JSR-330 EG a year ago. We had good discussions but none of our wishes was
worked out because WE failed to make final suggestions!
The atinject EG (Bob, Jürgen) has been responsive. At least MUCH more responsive
than other EG leaders these days... So I fail to see why the atinject EG is
'inactive since 5 years'. That's just wrong information.
3.) We cannot simply take the javax.inject package and maintain it in CDI. It is
forbidden to split a java package into multiple specs.
4.) We also cannot just amend the annotations and take them 'over'. That
would require the EC to officially move the maintenance of atinject to the CDI
EG. Or even requires a handover from the atinject EG. I'm not sure about
that
5.) again: WHAT DO WE GAIN? I always hear claims that it would be oh so great.
But then again: Show me an example what we would gain from it! Stop trashtalking
but show CODE instead!
6.) Our CDI-2.0 roadmap is full of stuff we still need to deliver. The EG is
busy as hell to get this done. You might add this to a CDI-3.0 wishlist, but
that's it for now imo.
7.) The JSR-330 spec had an important political role back then. I know most
people don't know that, but it's still great to have this little peace
which managed to make peace. Not peace between Spring and EE as many people
believe, back then it was more that it brought mainly peace between CDI and most
of the rest of JavaEE EGs! Remember that we haven't been allowed to target
Java SE in CDI-1.0? Remember that we were force to have the 'for Java
Enterprise' in the spec name? Remember that we had big battles with EJB? No,
then just take it as granted and let it rest...
LieGrue,
strub
_______________________________________________
cdi-dev mailing list
cdi-dev(a)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.
11:12 a.m.
New subject: Merging JSR-330 into CDI
On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
3.) We cannot simply take the javax.inject package and maintain it in
CDI.
It is forbidden to split a java package into multiple specs.
Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI
owning both javax.enterprise and javax.inject, or a single package being
owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0
and CDI 2/3.x?
11:58 a.m.
New subject: Merging JSR-330 into CDI
It's fine to have one spec own multiple packages. But one package shall not get
maintained by multiple specs.
Think about how sealed jars or OSGi should handle this -> technically broken and also
not allowed by the JCP rules.
Thus before we seriously think about that we need to know what features we like to get
from JSR-330.
I mean I'm really happy to have all this enthusiasm, but in the end it needs to turn
into real progress.
There are sooo many pull requests waiting to get reviewed first!
* CDI-SE needs a total rework for example
* the Builders need a review
etc
LieGrue,
strub
On Sunday, 20 March 2016, 11:12, arjan tijms <arjan.tijms(a)gmail.com> wrote:
On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
3.) We cannot simply take the javax.inject package and maintain it in CDI. It is forbidden
to split a java package into multiple specs.
>
Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI owning both
javax.enterprise and javax.inject, or a single package being owned by multiple specs, e.g.
javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?
2:47 p.m.
New subject: Merging JSR-330 into CDI
On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
It's fine to have one spec own multiple packages. But one package
shall
not get maintained by multiple specs.
Think about how sealed jars or OSGi should handle this -> technically
broken and also not allowed by the JCP rules.
Okay, and then it just concerns the package itself, right? Not any parent
packages. As javax.security as parent package is shared by both JASPIC and
JACC, while the parent itself is proposed for JSR 375.
Kind regards,
Arjan Tijms
Thus before we seriously think about that we need to know what features we
like to get from JSR-330.
I mean I'm really happy to have all this enthusiasm, but in the end it
needs to turn into real progress.
There are sooo many pull requests waiting to get reviewed first!
* CDI-SE needs a total rework for example
* the Builders need a review
etc
LieGrue,
strub
On Sunday, 20 March 2016, 11:12, arjan tijms <arjan.tijms(a)gmail.com>
wrote:
>
>
>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
>
>3.) We cannot simply take the javax.inject package and maintain it in
CDI. It is forbidden to split a java package into multiple specs.
>>
>
>
>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI
owning both javax.enterprise and javax.inject, or a single package being
owned by multiple specs, e.g. javax.inject being owned by both AtInject 1.0
and CDI 2/3.x?
>
>
8:38 p.m.
New subject: Merging JSR-330 into CDI
Okay, and then it just concerns the package itself, right? Not any
parent packages. As javax.security as parent package is shared by both JASPIC and JACC,
while the parent itself is proposed for JSR 375.
Yes, at least as far as I understood.
LieGrue,
strub
On Sunday, 20 March 2016, 20:34, arjan tijms <arjan.tijms(a)gmail.com> wrote:
>
>
>On Sun, Mar 20, 2016 at 11:58 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
>
>It's fine to have one spec own multiple packages. But one package shall not get
maintained by multiple specs.
>>
>>Think about how sealed jars or OSGi should handle this -> technically broken
and also not allowed by the JCP rules.
>>
>
>
Okay, and then it just concerns the package itself, right? Not any
parent packages. As javax.security as parent package is shared by both JASPIC and JACC,
while the parent itself is proposed for JSR 375.
>
>
>Kind regards,
>Arjan Tijms
>
>
>
>
>>
>>Thus before we seriously think about that we need to know what features we like to
get from JSR-330.
>>
>>I mean I'm really happy to have all this enthusiasm, but in the end it needs
to turn into real progress.
>>
>>
>>There are sooo many pull requests waiting to get reviewed first!
>>
>>* CDI-SE needs a total rework for example
>>* the Builders need a review
>>
>>etc
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>On Sunday, 20 March 2016, 11:12, arjan tijms <arjan.tijms(a)gmail.com> wrote:
>>>
>>>
>>>On Sun, Mar 20, 2016 at 8:34 AM, Mark Struberg <struberg(a)yahoo.de>
wrote:
>>>
>>>3.) We cannot simply take the javax.inject package and maintain it in CDI. It
is forbidden to split a java package into multiple specs.
>>>>
>>>
>>>
>>>Do you mean it's forbidden for a spec to own multiple packages, e.g. CDI
owning both javax.enterprise and javax.inject, or a single package being owned by multiple
specs, e.g. javax.inject being owned by both AtInject 1.0 and CDI 2/3.x?
>>>
>>>
>>
>
>
>
>
2960
days inactive
2961
days old
7 comments
4 participants
participants (4)
-
arjan tijms -
Mark Struberg -
Stephan Knitelius -
Werner Keil