@ThreadScoped?
by Romain Manni-Bucau
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 <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>
8 years, 11 months
Re: [cdi-dev] @ThreadScoped?
by Mark Struberg
I'd say we could move a request context from EXCLUSIVE threadA to EXCLUSIVE threadA.
But we cannot make the same request scoped Bean accessible from multiple Threads at the same time.
Lgm
--------------------------------------------
On Sun, 20/3/16, Manfred Riem <mnriem(a)gmail.com> wrote:
Subject: Re: [cdi-dev] @ThreadScoped?
To: "Stephan Knitelius" <stephan(a)knitelius.com>
Cc: "Mark Struberg" <struberg(a)yahoo.de>, "Reza Rahman" <reza_rahman(a)lycos.com>, "cdi-dev" <cdi-dev(a)lists.jboss.org>
Date: Sunday, 20 March, 2016, 18:36
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(a)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(a)yahoo.de
<mailto: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(a)lycos.com
<mailto: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(a)yahoo.de
<mailto: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(a)gmail.com
<mailto: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(a)yahoo.de
<mailto: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(a)gmail.com
<mailto: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(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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
<mailto:cdi-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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
<mailto:cdi-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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
<mailto:cdi-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
<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
<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.
8 years, 11 months
Re: [cdi-dev] Merging JSR-330 into CDI
by Werner Keil
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
> ****************************************
>
8 years, 11 months
Merging JSR-330 into CDI
by Manfred Riem
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.
8 years, 11 months
Please review PR 270
by Antoine Sabot-Durand
Hi guys,
As we said during last meeting, we need to release an alpha of the API ASAP
to help TCK team in their work.
PR270 introduces a lot of new interfaces (and a class) so it will trigger a
lot of code on TCK side.
So if you have time to review it by the end of the week-end please do so.
https://github.com/cdi-spec/cdi/pull/270
Thanks
Antoine
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Thomas Andraschko (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Thomas Andraschko commented on CDI-527:
---------------------------------------
+1 for IgnoreUnproxyableMethod*s* to be more generic.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-527:
------------------------------------------
Good point [~manovotn]
+1 for {{IgnoreFinalMethodProxying}}
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 12 months
