Re: [cdi-dev] Time to start working on CDI lite
by Werner Keil
Seems, from Tapestry 5.3 on you can use both, so it doesn't look like it
completely abandoned its own:
https://tapestry.apache.org/using-jsr-330-standard-annotations.html
Luckily the 2 JSRs (with a bit of help and moderation by others) 299 and
330 did end up building on top of each other (in reverse order) rather than
reinventing the wheel and competing with other libraries even inside the
same platform or environment (like we see a lot in Java SE and to some
extent also in EE elsewhere;-)
Werner
On Sun, Aug 30, 2015 at 4:29 PM, Werner Keil <werner.keil(a)gmail.com> wrote:
> Looking at the requirements for SE Embedded (on the lower side of SE)
> probably helps:
>
> http://www.oracle.com/technetwork/java/embedded/embedded-se/documentation...
>
> The 3 MB binary app size Romain mentioned is a good example. Could be a
> bit steep for Embedded, but as an upper end it sounds reasonable.
>
> Btw. although Rod Johnson and Bob Lee were listed as co Spec Leads, pretty
> much every initial contribution and effort came from Google/Bob:
> https://jcp.org/en/jsr/detail?id=330
>
> The EG had a couple of others like Tapestry, but I am not sure, when it
> e.g. adopted JSR 330 instead of its own DI library if it ever fully
> supported it to date?
>
> Werner
>
> On Sun, Aug 30, 2015 at 4:11 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: Time to start working on CDI lite (Romain Manni-Bucau)
>> 2. Re: Time to start working on CDI lite (Werner Keil)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Aug 2015 16:02:32 +0200
>> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
>> Subject: Re: [cdi-dev] Time to start working on CDI lite
>> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Message-ID:
>> <CACLE=
>> 7Mu5mMB3tFWLtPxNXRpKrR82xKku5saFB9it3n-8RU1aQ(a)mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Lite can have several definition, let's try to list them up if it can
>> help:
>>
>> - binary size: for me until 3M for an app it is "Lite"
>> - features number: the whole IoC set of feature is light since you almost
>> always need it, it means you can do lighter but it wouldnt be used - check
>> spring, who uses only spring-ioc and not context or more?
>> - features complexity: sure we are not light here but supporting scopes
>> already breaks "Lite-ness" IMO so not a real issue
>>
>> So my view is CDI "SE" is light enough - as a spec and spec can't affect
>> implementations so seems the fight is not on the right side to me.
>>
>>
>>
>> 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>
>>
>> 2015-08-30 15:57 GMT+02:00 Antonio Goncalves <antonio.goncalves(a)gmail.com
>> >:
>>
>> > It's funny, I feel I'm in Rod Johnson shoes back in Java EE 6 where he
>> > forked 330 because he found CDI was doing too much ;o)
>> >
>> > For me, "CDI Lite" was just basic dependency injection. The fact that
>> CDI
>> > can now run on SE (like JPA....), is good... but for me it has nothing
>> to
>> > do with Light : it's the entire thing that can bootstrap in SE. Good.
>> >
>> > So what is Lite for you guys ?
>> >
>> > Antonio
>> >
>> > On Sun, Aug 30, 2015 at 3:44 PM, Romain Manni-Bucau <
>> rmannibucau(a)gmail.com
>> > > wrote:
>> >
>> >> 2015-08-30 15:22 GMT+02:00 John D. Ament <john.d.ament(a)gmail.com>:
>> >>
>> >>> Personally, I'm not in favor of a slimmed down runtime. It was tried
>> >>> with EJB, but never implemented properly (most implementations that
>> support
>> >>> EJB-lite actually support the entire thing, except for deprecated
>> stuff).
>> >>>
>> >>>
>> >> +1, most of CDI is basic and quickly any light version will miss events
>> >> or other thing - in particular in maintaining micro services from
>> >> experience. Size of an implementation can easily be < 1M so not sure it
>> >> would bring anything. Only important point is what Antoine started to
>> do ie
>> >> ensuring EE and SE parts are clearly identified and split in the spec.
>> >>
>> >>
>> >>> I think if we define SE properly we won't have a need for this.
>> >>>
>> >>> John
>> >>>
>> >>> On Sun, Aug 30, 2015 at 8:07 AM Antonio Goncalves <
>> >>> antonio.goncalves(a)gmail.com> wrote:
>> >>>
>> >>>> @Antoine, so which content do you see in CDI Lite ? Are you sure
>> about
>> >>>> events ?
>> >>>>
>> >>>> I'm in favor of a "fatter" 330 that would have :
>> >>>>
>> >>>> - @Inject : already there
>> >>>> - @Qualifier : already there
>> >>>> -
>> >>>> *Producers and disposers *
>> >>>> -
>> >>>> *Programatic lookup *
>> >>>> - *Java SE Bootstrap*
>> >>>>
>> >>>> When you say "*The goal here is not to propose a new EE profile but a
>> >>>> subspec*", 330 could already be seen as a subspec. If you put events
>> >>>> apparts, what would be missing in this list in your point of view ?
>> And
>> >>>> what obstacles do you see in archieving this ?
>> >>>>
>> >>>> To boostrap CDI we have a CDIProvider, why not having an
>> >>>> InjectionProvider just to bootstrap 330 (then, CDIProvider could
>> extend
>> >>>> InjectionProvider, so it bootstraps the all thing) ?
>> >>>>
>> >>>> Antonio
>> >>>>
>> >>>> On Sun, Aug 30, 2015 at 9:09 AM, Antoine Sabot-Durand <
>> >>>> antoine(a)sabot-durand.net> wrote:
>> >>>>
>> >>>>> Yes Arjan, I think it's the first reason. We really should work with
>> >>>>> them to understand what should be added to CDI 2.0 to have it as a
>> first
>> >>>>> citizen DI in their spec.
>> >>>>>
>> >>>>> Le sam. 29 ao?t 2015 ? 23:15, arjan tijms <arjan.tijms(a)gmail.com> a
>> >>>>> ?crit :
>> >>>>>
>> >>>>>> On Sat, Aug 29, 2015 at 8:45 PM, Antonio Goncalves
>> >>>>>> <antonio.goncalves(a)gmail.com> wrote:
>> >>>>>> > I remember talking with the JAX-RS guys (Java EE), years ago
>> (back
>> >>>>>> in EE6),
>> >>>>>> > and their answer for not adopting CDI was "too heavy".
>> >>>>>>
>> >>>>>> I can't find an exact reference anymore, but I somewhat remember
>> that
>> >>>>>> one of the reasons was also simply that CDI as a general solution
>> >>>>>> finished late in Java EE 6, while JAX-RS finished earlier and had
>> all
>> >>>>>> the work for their own DI solution already done.
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Antonio Goncalves
>> >>>> Software architect, Java Champion and Pluralsight author
>> >>>>
>> >>>> Web site <http://www.antoniogoncalves.org> | Twitter
>> >>>> <http://twitter.com/agoncal> | LinkedIn
>> >>>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> >>>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves>
>> | Paris
>> >>>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >>>> _______________________________________________
>> >>>> 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.
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Antonio Goncalves
>> > Software architect, Java Champion and Pluralsight author
>> >
>> > Web site <http://www.antoniogoncalves.org> | Twitter
>> > <http://twitter.com/agoncal> | LinkedIn
>> > <http://www.linkedin.com/in/agoncal> | Pluralsight
>> > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
>> Paris
>> > JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150830/db8e0477/at...
>>
>>
>> End of cdi-dev Digest, Vol 57, Issue 33
>> ***************************************
>>
>
>
9 years, 6 months
- 1
- 0
Exploring the interest of mutating bean manager at runtime
by Antoine Sabot-Durand
Hi all,
This topic (modifying bean meta data at runtime) has been coming and going
since CDI 1.0.
As we are moving to Java SE with potentially more dynamic env, I think
interesting to see if there is a real need to explore it.
It's a very disruptive feature and obviously costly to add to the spec, so
I think we should start gathering proof that it would bring more power and
new usage to CDI before discussing all the problems it could raise.
I propose to g that way:
1) Launch a public consultation to ask our user if they are interested and
more than all give use real use case where it would solve a problem
2) Analyse these use cases to see if they are real or as some people think
are only a lack of knowledge of the spec
3) From there we could either left this aside if nothing relevant comes out
or start discussing the constraint around this feature.
Wdyt?
Antoine
9 years, 6 months
- 2
- 2
Problem with JDK8 u60 and synthesized methods for lambdas now exposing annotations
by arjan tijms
Hi,
We just discovered an issue where using a lambda in an observer method
results in a synthesized method for that lambda that since u60 makes
the @Observes annotation visible. This will cause CDI (Weld
2.2.2.Final in this case as shipped with GlassFish 4.1) to see this
generated method as an actual observer method.
See the following mail on the OpenJDK list for details:
http://mail.openjdk.java.net/pipermail/lambda-dev/2015-August/012146.html...
The suggestion there is that it's simply a bug in the CDI implementation.
I wonder, should the CDI spec in general say that synthesized methods
should be ignored when scanning for observer (and possible other)
methods? I briefly scanned through the spec but didn't see any
references to synthesized methods.
Kind regards,
Arjan Tijms
9 years, 6 months
- 5
- 5
Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
Jozef,
Can't say to what extent this could also apply for JMS but just wanted to
point to the recent Portlet 3 draft
https://java.net/downloads/portletspec3/SpecDrafts/PortletSpec3-Draft1-20...
(20.2 Custom Scopes) where the JSR intends to add new CDI scopes for
certain parts of the standard while using the ones Java EE/CDI defines in
other cases.
Werner
On Wed, Aug 26, 2015 at 3:50 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Werner Keil)
> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Jozef Hartinger)
> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Nigel Deakin)
>
>
> ----------------------------------------------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 15:04:06 +0200
> From: Jozef Hartinger <jharting(a)redhat.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>, Romain Manni-Bucau
> <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DDB946.9050208(a)redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> To me the proposed approach seems to be very strict about JMS semantics
> and bending CDI over it (not using CDI contextual instances properly,
> calling @RequestScoped instances from multiple threads in parallel, ..).
>
> A simpler approach would be a bridge where a JMS message would produce a
> single CDI event. The semantics of synchronous CDI events would apply
> from there. For users this should be straightforward as they would know
> that they are working with a CDI event that was raised by the container
> when it received a JMS message.
>
> Jozef
>
>
> On 26.08.2015 11:43, Nigel Deakin wrote:
> > > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> > >>
> > >> For this last case a really elegant solution would be to just reuse
> > >> @Observes to fire the message from the jms "container" listener and
> > >> propagate it to the "user" listener. This would then allow to
> decouple
> > >> the application listener from JMS.
> >
> > On 25/08/2015 15:26, Jozef Hartinger wrote:
> >> Agreed. I think we should leverage the existing CDI event/observer
> >> functionality instead of introducing a completely new
> >> delivery mechanism.
> >
> > Can you please say a bit more about what you have in mind?
> >
> > Romain suggests using events to invoke the "user" listener from the "JMS
> > container listener".
> > That's a useful distinction. Just to clarify the terminology:
> >
> > "user" listener = listener bean provided by the application
> > "JMS container listener" = JMS consumer provided by the application
> > server or resource adapter
> >
> > There needs to be one consumer for every listener bean since the two
> > need to have the same lifecycle, and also so we can implement JMS queue
> > sematics which require that a message from a queue is delivered to one
> > and only one listener.
> >
> > The transaction needs to be started by the consumer before invoking the
> > listener and ended after the listener returns. This allows the
> > acknowledgement of the message (which is performed by the consumer) to
> > take place in the same transaction as is used by the listener's method.
> >
> > Currently I'm proposing that the "consumer" invokes the "listener" by a
> > simple method call. I suppose instead of simply invoking the method it
> > could fire a synchronous event, which only the associated listener
> > instance would receive, but I'm not sure what the benefit of this would
> > be. Since JMS semantics are very different from CDI event semantics I
> > think there's a danger that this will be confusing, since the user might
> > think they were getting CDI event semantics, but they were actually
> > getting JMS semantics.
> >
> > Since this is a bit of a FAQ, it might be useful to explore the
> > differences between the two semantics, but currently they seem
> > profoundly different to me. That's why my proposals are built on the CDI
> > bean lifecycle model but not the CDI event observer model.
> >
> > Nigel
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 14:50:26 +0100
> From: Nigel Deakin <nigel.deakin(a)oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DDC422.7000907(a)oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 26/08/2015 13:26, arjan tijms wrote:
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 2:03 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> wrote:
> >> In the case of a "JMS listener bean" with @RequestScoped (or any scope,
> >> really) then the JMS consumer (the thread which receives a message from
> the
> >> JMS server and invokes the listener) is associated with the actual bean
> >> instance.
> >
> > Indeed, so the call takes place in the context of the JMS consumer
> > thread and happens to the "bare" bean instance and does not go through
> > the proxy that's normally used to access that bean.
> >
> >
> >> However once you're inside the callback method then this request scope
> >> (which relates to a different thread) is not available.
> >
> > So this would be an important detail for the user to take into
> > account. The callback method is NOT allowed to access any other normal
> > scoped beans, be it via injection, beanmanager lookup or whatever.
> >
> > E.g. given:
> >
> > @RequestScoped
> > public class MyCDIBean21 {
> >
> > @Inject
> > private MyRequestScopedBean requestBean;
> >
> >
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC
> > )
> > @JMSConnectionFactory("java:global/MyCF")
> > @MessageSelector("ticker='ORCL'")
> > public void processNewsItem(String newsItem) {
> > ...
> > }
> > }
> >
> > Then the callback processNewsItem() can not use requestBean, since
> > it's a proxy and it will try to delegate to a scope that does not
> > exist for that thread.
> >
> > Alternative, if there's an other @RequestScope active (as suggested
> > below) it will end up calling a different bean instance than the user
> > may expect.
>
> Yes, I can see how that might be surprising.
>
> However it looks as if this is exactly what is proposed in CDI 2.0 for
> asynchronous observer methods:
>
> 10.5.3 "Observer method invocation context" states "If the observer method
> is asynchronous, it is called in a new
> lifecycle contexts, a new transaction context but the same security
> context as the invocation of Event.fireAsync()."
>
> 19.3.1. "Request context lifecycle in Java EE". States that "The request
> scope is active...during any asynchronous
> invocation of an event observer".
>
> Please correct me if I have misunderstood what is proposed.
>
> > While it could work, I wonder if this aspect wouldn't be a bit confusing?
>
> Good question!
>
> Nigel
>
>
> ------------------------------
>
> _______________________________________________
> 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 57, Issue 25
> ***************************************
>
9 years, 6 months
- 1
- 0
Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
I can confirm, in my example for routing events, the BookingBean injected
into a BookingMDB and listening Observer class also had to
be @RequestScoped.
Werner
On Wed, Aug 26, 2015 at 2:03 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Nigel Deakin)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (John D. Ament)
>
> ----------------------------------------------------------------------
>
> Message: 2
> Date: Wed, 26 Aug 2015 11:10:11 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>, arjan tijms
> <arjan.tijms(a)gmail.com>, Romain Manni-Bucau <
> rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAOqetn8LhNvq+4ELzuq-MLA3=6eVP3-k_AMQ8502=
> ag4jy4ZCg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Aug 26, 2015 at 6:53 AM Nigel Deakin <nigel.deakin(a)oracle.com>
> wrote:
>
> > On 26/08/2015 10:51, arjan tijms wrote:
> > > On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> > > <rmannibucau(a)gmail.com> wrote:
> > >> Agree for provided scope but JMS + short time scopes will not match
> > well in
> > >> practise so i would worry more about not "default" scopes which can
> miss
> > >> these events.
> > >
> > > Short lived scopes like @RequestScoped may not be the best match
> indeed.
> > >
> > > Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> > > thing, e.g. there's the expectation that only the current thread will
> > > access it. If the JMS provider will asynchronously call a method on
> > > the bean instance from another thread, then this breaks this
> > > assumption.
> >
> > That's an interesting point. Is there anything in the CDI spec which
> would
> > forbid the use of a @RequestScoped JMS
> > listener bean from another thread?
> >
>
> The CDI spec still mandates that a request scope is started for delivery to
> MDBs. See
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#request_context
>
> The JMS provider would be responsible for retrieving a contextual reference
> to the bean and then invoking the method. The container should still be
> responsible for starting the request context (If I read this correctly).
>
> Likewise, we could say that a @TransactionScoped bean also applies here,
> since a JTA transaction should have been started by the RA.
>
>
> >
> > Perhaps all that is needed is to make it clear to users that this is what
> > would happen. The same issue would arise if
> > the user injected a dependent-scoped JMS listener bean into a
> > @RequestScoped bean.
> >
> > It's worth considering threading more generally. Although the JMS
> provider
> > (resource adapter, actually) can make sure
> > that the callback method won't be called from multiple JMS provider
> > threads at the same time, it can't guarantee that an
> > application thread won't be calling a business method on the bean at the
> > same time. (Would it want to?)
> >
> > Nigel
> > _______________________________________________
> > 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/20150826/bb408008/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 57, Issue 24
> ***************************************
>
9 years, 6 months
- 1
- 0
Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
Good point. What I tried to sketch out from my example here was mapping a
"JMS container listener" (MDB) to a "business" or "user" listener making
sense for the business logic of a particular application domain.
Werner
On Wed, Aug 26, 2015 at 12:10 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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Nigel Deakin)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Werner Keil)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Aug 2015 10:43:40 +0100
> From: Nigel Deakin <nigel.deakin(a)oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Jozef Hartinger <jharting(a)redhat.com>, Romain Manni-Bucau
> <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DD8A4C.7050107(a)oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> >>
> >> For this last case a really elegant solution would be to just reuse
> >> @Observes to fire the message from the jms "container" listener and
> >> propagate it to the "user" listener. This would then allow to decouple
> >> the application listener from JMS.
>
> On 25/08/2015 15:26, Jozef Hartinger wrote:
> > Agreed. I think we should leverage the existing CDI event/observer
> functionality instead of introducing a completely new
> > delivery mechanism.
>
> Can you please say a bit more about what you have in mind?
>
> Romain suggests using events to invoke the "user" listener from the "JMS
> container listener".
> That's a useful distinction. Just to clarify the terminology:
>
> "user" listener = listener bean provided by the application
> "JMS container listener" = JMS consumer provided by the application server
> or resource adapter
>
> There needs to be one consumer for every listener bean since the two need
> to have the same lifecycle, and also so we can
> implement JMS queue sematics which require that a message from a queue is
> delivered to one and only one listener.
>
> The transaction needs to be started by the consumer before invoking the
> listener and ended after the listener returns.
> This allows the acknowledgement of the message (which is performed by the
> consumer) to take place in the same
> transaction as is used by the listener's method.
>
> Currently I'm proposing that the "consumer" invokes the "listener" by a
> simple method call. I suppose instead of simply
> invoking the method it could fire a synchronous event, which only the
> associated listener instance would receive, but
> I'm not sure what the benefit of this would be. Since JMS semantics are
> very different from CDI event semantics I think
> there's a danger that this will be confusing, since the user might think
> they were getting CDI event semantics, but they
> were actually getting JMS semantics.
>
> Since this is a bit of a FAQ, it might be useful to explore the
> differences between the two semantics, but currently
> they seem profoundly different to me. That's why my proposals are built on
> the CDI bean lifecycle model but not the CDI
> event observer model.
>
> Nigel
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Aug 2015 11:46:57 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7MYErwNimYDz=
> 5C5+xD5MFV-T8M6wjyw9Ax8p59T6Z2ww(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Something I didnt think before but if you can register a method reference
> then CDI event system starts to be useless:
>
> xxx.register(myCdiBean::listenOn);
>
> can be something to investigate API wise maybe
>
>
> 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>
>
> 2015-08-26 11:43 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com>:
>
> > > On 25.08.2015 16:05, Romain Manni-Bucau wrote:
> > >>
> > >> For this last case a really elegant solution would be to just reuse
> > >> @Observes to fire the message from the jms "container" listener and
> > >> propagate it to the "user" listener. This would then allow to decouple
> > >> the application listener from JMS.
> >
> > On 25/08/2015 15:26, Jozef Hartinger wrote:
> >
> >> Agreed. I think we should leverage the existing CDI event/observer
> >> functionality instead of introducing a completely new
> >> delivery mechanism.
> >>
> >
> > Can you please say a bit more about what you have in mind?
> >
> > Romain suggests using events to invoke the "user" listener from the "JMS
> > container listener".
> > That's a useful distinction. Just to clarify the terminology:
> >
> > "user" listener = listener bean provided by the application
> > "JMS container listener" = JMS consumer provided by the application
> server
> > or resource adapter
> >
> > There needs to be one consumer for every listener bean since the two need
> > to have the same lifecycle, and also so we can implement JMS queue
> sematics
> > which require that a message from a queue is delivered to one and only
> one
> > listener.
> >
> > The transaction needs to be started by the consumer before invoking the
> > listener and ended after the listener returns. This allows the
> > acknowledgement of the message (which is performed by the consumer) to
> take
> > place in the same transaction as is used by the listener's method.
> >
> > Currently I'm proposing that the "consumer" invokes the "listener" by a
> > simple method call. I suppose instead of simply invoking the method it
> > could fire a synchronous event, which only the associated listener
> instance
> > would receive, but I'm not sure what the benefit of this would be. Since
> > JMS semantics are very different from CDI event semantics I think
> there's a
> > danger that this will be confusing, since the user might think they were
> > getting CDI event semantics, but they were actually getting JMS
> semantics.
> >
> > Since this is a bit of a FAQ, it might be useful to explore the
> > differences between the two semantics, but currently they seem profoundly
> > different to me. That's why my proposals are built on the CDI bean
> > lifecycle model but not the CDI event observer model.
> >
> > Nigel
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a1a16971/at...
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 11:51:30 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhBb6e_LM4OV3zyH_k-g7PpBN=3=
> DAyVa3C54+2EtBK7-g(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Aug 26, 2015 at 11:09 AM, Romain Manni-Bucau
> <rmannibucau(a)gmail.com> wrote:
> > Agree for provided scope but JMS + short time scopes will not match well
> in
> > practise so i would worry more about not "default" scopes which can miss
> > these events.
>
> Short lived scopes like @RequestScoped may not be the best match indeed.
>
> Additionally, @RequestScoped is kinda assumed to be an "@ThreadScoped"
> thing, e.g. there's the expectation that only the current thread will
> access it. If the JMS provider will asynchronously call a method on
> the bean instance from another thread, then this breaks this
> assumption.
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 12:10:37 +0200
> From: Werner Keil <werner.keil(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CAAGawe1bxW1oA_s4t0RNPJCf2hQYgRMsPJatB-M8BCy7xuwRoA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> public class JmsRegistrar {
> @Inject
> @JmsConnectionFactory(...)
> private ConnectionFactory factory;
>
> @Inject
> @JmsQueue(...)
> private Queue queue;
>
> public void startJms(@Observes JmsStart start) {
> start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
> .register(BookingListener.class) // with defaults for all
> potential config
> .listenOn(queue)
> .register(BookingListener2.class, new BookingLiteral2())
> .withMaxSessions(10)
> .listenOn(Queue.class, new QueueLiteral(...))
> ......;
> }
> }
>
>
> it could allow to accomplish what I did (loosely based on
> http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
> events to custom CDI ones like that.
>
> Class BookingMDB:
>
> @Inject
> private BookingBean booker;
>
> public void onMessage(Message rcvMessage) {
> BytesMessage msg = null;
> try {
> if (rcvMessage instanceof BytesMessage) {
> msg = (BytesMessage) rcvMessage;
> byte[] output = new byte[5];
> msg.readBytes(output);
> booker.book(output);
> } else {
> LOGGER.warning("Message of wrong type: " +
> rcvMessage.getClass().getName());
> }
> } catch (JMSException e) {
> throw new RuntimeException(e);
> }
> }
> Class BookingBean:
> public void book(byte[] msg) {
> BookingEvent bookingEvent = new BookingEvent();
> if (msg[256] = 42}
> bookingEvent.setType(BookingType.OK);
> } else {
> <some other message data triggering a different booking event>
> }
> bookingEvent.setMessage(msg);
> bookingEvent.setDatetime(LocalDateTime.now());
>
> switch (bookingEvent.getType()) {
> case OK:
> BookingEventProducer.fire(bookingEvent);
> break;
> case [...]
> default:
> LOGGER.severe("invalid booking option");
> break;
> }
> }
>
> You'll get the idea about other types involved from the standard CDI
> example.
> We're dealing with BytesMessage because part of that booking process
> happens on host servers;-)
>
> Werner
>
> On Wed, Aug 26, 2015 at 11:16 AM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (arjan tijms)
> > 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (arjan tijms)
> > 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (Romain Manni-Bucau)
> > 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (Nigel Deakin)
> > 5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (arjan tijms)
> > 6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (Romain Manni-Bucau)
> > 7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> > EE application to listen for JMS messages (Romain Manni-Bucau)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 25 Aug 2015 22:53:21 +0200
> > From: arjan tijms <arjan.tijms(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin(a)oracle.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAE=-AhCnTyS-ZVAfT9k2jDK=
> > k6QHW4ShUab_Vt+e6WmBN76gWg(a)mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 25 Aug 2015 23:16:27 +0200
> > From: arjan tijms <arjan.tijms(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin(a)oracle.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAE=-
> > AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> > wrote:
> > > Someone over on the JMS user alias told me about this yesterday. So
> that
> > > would avoid the need to call a method to trigger lazy initialisation on
> > > normal-scoped bean proxies. I presume the application still has to
> inject
> > > the bean.
> >
> > The bean does not necessarily have to be injected at any point.
> >
> > With @Eager it will be activated and its @PostConstruct method will be
> > invoked in case it hadn't been referenced before (which in case of
> > @Eager is unlikely, as it instantiates very early, but still
> > theoretically possible).
> >
> > The bean can of course still be injected or otherwise referenced later
> > within the same scope, but as mentioned this is not required.
> >
> > So for example if you have OmniFaces on your classpath and then only
> > the following bean in an application:
> >
> > @Eager
> > @ApplicationScoped
> > public class MyEagerApplicationScopedBean {
> >
> > @PostConstruct
> > public void init() {
> > System.out.println("Application scoped init!");
> > }
> > }
> >
> > Then you'll see "Application scoped init!" being printed in your
> > server log when you deploy that application. No other code is needed.
> >
> >
> > > If so then it sounds useful. Is it going to be included as a standard
> > > feature of CDI 2.0? I see someone has proposed
> > > https://issues.jboss.org/browse/CDI-473 .
> >
> > As the issue already mentions, this is possible with current day CDI
> > already. The proposal may arguably make it a little more concise and a
> > little less verbose. An eager attribute on the scope looks like a
> > quite minimal and elegant solution. Additionally it may make sense for
> > some scopes to restrict for which "IDs' it's eagerly instantiated
> > (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> > @FlowScoped, etc).
> >
> > A new @Startup seems more like a very specific usage of the eager
> > attribute, namely for @ApplicationScoped (or Singleton?) beans.
> >
> > Kind regards,
> > Arjan
> >
> >
> >
> >
> >
> > >
> > > Nigel
> > >
> > >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 26 Aug 2015 10:11:21 +0200
> > From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: arjan tijms <arjan.tijms(a)gmail.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> > SyQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
> >
> > > Hi,
> > >
> > > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)oracle.com
> >
> > > wrote:
> > > > On 25/08/2015 12:38, arjan tijms wrote:
> > > > This looks very interesting. Does this work with any normal scope?
> > >
> > > Yes, all normal scopes that are available in standard Java EE support
> > > this as far as I know.
> > >
> > >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2
> > - so JMS can't rely on it for custom normal scopes.
> >
> >
> > > There's the small caveat that CDI itself doesn't know about this
> > > automatically for any custom normal scope. That implementation of such
> > > scope (via a Context) must explicitly throw these events.
> > >
> > > For example, this is what Mojarra does for the @FlowScoped
> > implementation:
> > >
> > >
> > >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> > >
> > > Which is fired when the scope starts here:
> > >
> > >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> > >
> > > (the exact same code is used for @ViewScoped in Mojarra as well)
> > >
> > >
> > > > then every time a new request starts, this event is fired which
> causes
> > an
> > > > instance of the bean to be created for that request?
> > >
> > > Yes, that is what this does ;)
> > >
> > > Kind regards,
> > > Arjan Tijms
> > > _______________________________________________
> > > 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/20150826/c1f05f1c/at...
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 26 Aug 2015 10:07:01 +0100
> > From: Nigel Deakin <nigel.deakin(a)oracle.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID: <55DD81B5.9040407(a)oracle.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > (Tidying up the top-posting...)
> >
> > Romain Manni-Bucau:
> > > ...I see it really nice to not rely only on annotation - and aligned
> > with
> > > most specs - since sometimes you just want to either be able to rely
> on
> > a
> > > loop or a custom config to register your listeners. Annotations are
> too
> > > rigid for such cases.
> >
> > Nigel:
> > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > declarative), then they would use the normal JMS API. The existing
> > > API to register an async message listener isn't good enough,
> > > and we may improve it in JMS 2.1, but that's not something that
> > > I'd want to bother the people on cdi-dev with.
> >
> > Romain Manni-Bucau:
> > > Integrating it in CDI lifecycle through an event allow CDI users to
> > still
> > > use it in the right phase of the container boot so it is still
> important
> > > IMO and avoid all users to have their own custom listener for it -
> > > @Initialized(AppScoped.class). Also allow to enrich the API through
> the
> > event
> > > itself making things smoother IMO.
> >
> > Nigel:
> > > I'm sorry I don't understand you.
> > > I thought you were asking about an API which does not use annotation.
> >
> > Romain Manni-Bucau:
> > > Both are needed (like websocket spec). Annotation one is nice for
> fully
> > business
> > > code and/or simple libs but relying on CDI allows to simplify the
> > wiring since you
> > > can reuse CDI beans under the hood ie have an implicit connection
> > factory if
> > > there is a single one etc which is not possible in fully SE context.
> >
> > Can you explain the distinction you're making here? You seem to be
> > suggesting two alternatives, using "annotation" and
> > "relying on CDI". What would an application which uses CDI but which
> > doesn't use annotation look like?
> >
> > Nigel
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 26 Aug 2015 11:07:46 +0200
> > From: arjan tijms <arjan.tijms(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAE=-
> > AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q(a)mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau(a)gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 26 Aug 2015 11:09:30 +0200
> > From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: arjan tijms <arjan.tijms(a)gmail.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> > kL6gyb5jHb7fdA(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
> >
> > > Hi,
> > >
> > > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > > <rmannibucau(a)gmail.com> wrote:
> > > >> Yes, all normal scopes that are available in standard Java EE
> support
> > > >> this as far as I know.
> > > >>
> > > >
> > > > Events are not mandatory for a normal scope - at least was the case
> in
> > > 1.2 -
> > > > so JMS can't rely on it for custom normal scopes.
> > >
> > > Absolutely true, but that was exactly what I said ;)
> > >
> > > All Java EE provided scopes throw the events. For CDI, this is
> > > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > > @ApplicationScoped and @ConversationScoped.
> > >
> > > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > > have to double check whether this is actually in the spec for those
> > > last two and if not see if we can update it for 2.3.
> > >
> > >
> > Agree for provided scope but JMS + short time scopes will not match well
> in
> > practise so i would worry more about not "default" scopes which can miss
> > these events.
> >
> >
> > > Kind regards,
> > > Arjan Tijms
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/at...
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 26 Aug 2015 11:16:04 +0200
> > From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> > Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> > in a Java EE application to listen for JMS messages
> > To: Nigel Deakin <nigel.deakin(a)oracle.com>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> > Message-ID:
> > <CACLE=
> > 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com>:
> >
> > > (Tidying up the top-posting...)
> > >
> > > Romain Manni-Bucau:
> > > > ...I see it really nice to not rely only on annotation - and aligned
> > with
> > > > most specs - since sometimes you just want to either be able to rely
> > on a
> > > > loop or a custom config to register your listeners. Annotations are
> too
> > > > rigid for such cases.
> > >
> > > Nigel:
> > > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > > declarative), then they would use the normal JMS API. The existing
> > > > API to register an async message listener isn't good enough,
> > > > and we may improve it in JMS 2.1, but that's not something that
> > > > I'd want to bother the people on cdi-dev with.
> > >
> > > Romain Manni-Bucau:
> > > > Integrating it in CDI lifecycle through an event allow CDI users to
> > still
> > > > use it in the right phase of the container boot so it is still
> > important
> > > > IMO and avoid all users to have their own custom listener for it -
> > > > @Initialized(AppScoped.class). Also allow to enrich the API through
> the
> > > event
> > > > itself making things smoother IMO.
> > >
> > > Nigel:
> > > > I'm sorry I don't understand you.
> > > > I thought you were asking about an API which does not use annotation.
> > >
> > > Romain Manni-Bucau:
> > > > Both are needed (like websocket spec). Annotation one is nice for
> fully
> > > business
> > > > code and/or simple libs but relying on CDI allows to simplify the
> > wiring
> > > since you
> > > > can reuse CDI beans under the hood ie have an implicit connection
> > > factory if
> > > > there is a single one etc which is not possible in fully SE context.
> > >
> > > Can you explain the distinction you're making here? You seem to be
> > > suggesting two alternatives, using "annotation" and "relying on CDI".
> > What
> > > would an application which uses CDI but which doesn't use annotation
> look
> > > like?
> > >
> > >
> > The sample I gave before with the JmsStart event basically:
> >
> >
> > public class JmsRegistrar {
> > @Inject
> > @JmsConnectionFactory(...)
> > private ConnectionFactory factory;
> >
> > @Inject
> > @JmsQueue(...)
> > private Queue queue;
> >
> > public void startJms(@Observes JmsStart start) {
> > start.withFactory(factory) // withFactory should be optional if
> > only 1 bean matches it
> > .register(MyCdiTypedListener.class) // with defaults for
> all
> > potential config
> > .listenOn(queue)
> > .register(MyCdiTypedListener2.class, new MyLiteral())
> > .withMaxSessions(10)
> > .listenOn(Queue.class, new QueueLiteral(...))
> > ......;
> > }
> > }
> >
> >
> > The power of it appears when you have a config injection in JmsRegistrar
> > you can iterate over to get the list of listener for instance.
> >
> > Also JMS resources can be decorated and referenced from qualifiers
> instead
> > of instances thanks to CDI.
> >
> > It doesnt prevent the app to use @JmxListener somewhere else if the
> > listener doesnt need any input/config to be registered.
> >
> >
> > > Nigel
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 57, Issue 21
> > ***************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/c56ea2e7/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 57, Issue 22
> ***************************************
>
9 years, 6 months
- 1
- 0
Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
... with less code, sorry forgot to mention ;-)
Werner
On Wed, Aug 26, 2015 at 12:10 PM, Werner Keil <werner.keil(a)gmail.com> wrote:
> Hi,
>
> public class JmsRegistrar {
> @Inject
> @JmsConnectionFactory(...)
> private ConnectionFactory factory;
>
> @Inject
> @JmsQueue(...)
> private Queue queue;
>
> public void startJms(@Observes JmsStart start) {
> start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
> .register(BookingListener.class) // with defaults for all
> potential config
> .listenOn(queue)
> .register(BookingListener2.class, new BookingLiteral2())
> .withMaxSessions(10)
> .listenOn(Queue.class, new QueueLiteral(...))
> ......;
> }
> }
>
>
> it could allow to accomplish what I did (loosely based on
> http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
> events to custom CDI ones like that.
>
> Class BookingMDB:
>
> @Inject
> private BookingBean booker;
>
> public void onMessage(Message rcvMessage) {
> BytesMessage msg = null;
> try {
> if (rcvMessage instanceof BytesMessage) {
> msg = (BytesMessage) rcvMessage;
> byte[] output = new byte[5];
> msg.readBytes(output);
> booker.book(output);
> } else {
> LOGGER.warning("Message of wrong type: " +
> rcvMessage.getClass().getName());
> }
> } catch (JMSException e) {
> throw new RuntimeException(e);
> }
> }
> Class BookingBean:
> public void book(byte[] msg) {
> BookingEvent bookingEvent = new BookingEvent();
> if (msg[256] = 42}
> bookingEvent.setType(BookingType.OK);
> } else {
> <some other message data triggering a different booking event>
> }
> bookingEvent.setMessage(msg);
> bookingEvent.setDatetime(LocalDateTime.now());
>
> switch (bookingEvent.getType()) {
> case OK:
> BookingEventProducer.fire(bookingEvent);
> break;
> case [...]
> default:
> LOGGER.severe("invalid booking option");
> break;
> }
> }
>
> You'll get the idea about other types involved from the standard CDI
> example.
> We're dealing with BytesMessage because part of that booking process
> happens on host servers;-)
>
> Werner
>
> On Wed, Aug 26, 2015 at 11:16 AM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (arjan tijms)
>> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (arjan tijms)
>> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (Romain Manni-Bucau)
>> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (Nigel Deakin)
>> 5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (arjan tijms)
>> 6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (Romain Manni-Bucau)
>> 7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
>> EE application to listen for JMS messages (Romain Manni-Bucau)
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 26 Aug 2015 11:16:04 +0200
>> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
>> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
>> in a Java EE application to listen for JMS messages
>> To: Nigel Deakin <nigel.deakin(a)oracle.com>
>> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
>> Message-ID:
>> <CACLE=
>> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ(a)mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com>:
>>
>> > (Tidying up the top-posting...)
>> >
>> > Romain Manni-Bucau:
>> > > ...I see it really nice to not rely only on annotation - and aligned
>> with
>> > > most specs - since sometimes you just want to either be able to rely
>> on a
>> > > loop or a custom config to register your listeners. Annotations are
>> too
>> > > rigid for such cases.
>> >
>> > Nigel:
>> > > Obviously, if users don't want to use CDI (or MDBs, which are also
>> > > declarative), then they would use the normal JMS API. The existing
>> > > API to register an async message listener isn't good enough,
>> > > and we may improve it in JMS 2.1, but that's not something that
>> > > I'd want to bother the people on cdi-dev with.
>> >
>> > Romain Manni-Bucau:
>> > > Integrating it in CDI lifecycle through an event allow CDI users to
>> still
>> > > use it in the right phase of the container boot so it is still
>> important
>> > > IMO and avoid all users to have their own custom listener for it -
>> > > @Initialized(AppScoped.class). Also allow to enrich the API through
>> the
>> > event
>> > > itself making things smoother IMO.
>> >
>> > Nigel:
>> > > I'm sorry I don't understand you.
>> > > I thought you were asking about an API which does not use annotation.
>> >
>> > Romain Manni-Bucau:
>> > > Both are needed (like websocket spec). Annotation one is nice for
>> fully
>> > business
>> > > code and/or simple libs but relying on CDI allows to simplify the
>> wiring
>> > since you
>> > > can reuse CDI beans under the hood ie have an implicit connection
>> > factory if
>> > > there is a single one etc which is not possible in fully SE context.
>> >
>> > Can you explain the distinction you're making here? You seem to be
>> > suggesting two alternatives, using "annotation" and "relying on CDI".
>> What
>> > would an application which uses CDI but which doesn't use annotation
>> look
>> > like?
>> >
>> >
>> The sample I gave before with the JmsStart event basically:
>>
>>
>> public class JmsRegistrar {
>> @Inject
>> @JmsConnectionFactory(...)
>> private ConnectionFactory factory;
>>
>> @Inject
>> @JmsQueue(...)
>> private Queue queue;
>>
>> public void startJms(@Observes JmsStart start) {
>> start.withFactory(factory) // withFactory should be optional if
>> only 1 bean matches it
>> .register(MyCdiTypedListener.class) // with defaults for
>> all
>> potential config
>> .listenOn(queue)
>> .register(MyCdiTypedListener2.class, new MyLiteral())
>> .withMaxSessions(10)
>> .listenOn(Queue.class, new QueueLiteral(...))
>> ......;
>> }
>> }
>>
>>
>> The power of it appears when you have a config injection in JmsRegistrar
>> you can iterate over to get the list of listener for instance.
>>
>> Also JMS resources can be decorated and referenced from qualifiers instead
>> of instances thanks to CDI.
>>
>> It doesnt prevent the app to use @JmxListener somewhere else if the
>> listener doesnt need any input/config to be registered.
>>
>>
>> > Nigel
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 57, Issue 21
>> ***************************************
>>
>
>
9 years, 6 months
- 1
- 0
Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean in a Java EE application to listen for JMS messages
by Werner Keil
Hi,
public class JmsRegistrar {
@Inject
@JmsConnectionFactory(...)
private ConnectionFactory factory;
@Inject
@JmsQueue(...)
private Queue queue;
public void startJms(@Observes JmsStart start) {
start.withFactory(factory) // withFactory should be optional if
only 1 bean matches it
.register(BookingListener.class) // with defaults for all
potential config
.listenOn(queue)
.register(BookingListener2.class, new BookingLiteral2())
.withMaxSessions(10)
.listenOn(Queue.class, new QueueLiteral(...))
......;
}
}
it could allow to accomplish what I did (loosely based on
http://www.jboss.org/quickstarts/eap/payment-cdi-event/) forwarding MDB
events to custom CDI ones like that.
Class BookingMDB:
@Inject
private BookingBean booker;
public void onMessage(Message rcvMessage) {
BytesMessage msg = null;
try {
if (rcvMessage instanceof BytesMessage) {
msg = (BytesMessage) rcvMessage;
byte[] output = new byte[5];
msg.readBytes(output);
booker.book(output);
} else {
LOGGER.warning("Message of wrong type: " +
rcvMessage.getClass().getName());
}
} catch (JMSException e) {
throw new RuntimeException(e);
}
}
Class BookingBean:
public void book(byte[] msg) {
BookingEvent bookingEvent = new BookingEvent();
if (msg[256] = 42}
bookingEvent.setType(BookingType.OK);
} else {
<some other message data triggering a different booking event>
}
bookingEvent.setMessage(msg);
bookingEvent.setDatetime(LocalDateTime.now());
switch (bookingEvent.getType()) {
case OK:
BookingEventProducer.fire(bookingEvent);
break;
case [...]
default:
LOGGER.severe("invalid booking option");
break;
}
}
You'll get the idea about other types involved from the standard CDI
example.
We're dealing with BytesMessage because part of that booking process
happens on host servers;-)
Werner
On Wed, Aug 26, 2015 at 11:16 AM, <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: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 2. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 3. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 4. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Nigel Deakin)
> 5. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (arjan tijms)
> 6. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
> 7. Re: JMS 2.1: Proposal to allow any CDI managed bean in a Java
> EE application to listen for JMS messages (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 25 Aug 2015 22:53:21 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-AhCnTyS-ZVAfT9k2jDK=
> k6QHW4ShUab_Vt+e6WmBN76gWg(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> wrote:
> > On 25/08/2015 12:38, arjan tijms wrote:
> > This looks very interesting. Does this work with any normal scope?
>
> Yes, all normal scopes that are available in standard Java EE support
> this as far as I know.
>
> There's the small caveat that CDI itself doesn't know about this
> automatically for any custom normal scope. That implementation of such
> scope (via a Context) must explicitly throw these events.
>
> For example, this is what Mojarra does for the @FlowScoped implementation:
>
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
>
> (the exact same code is used for @ViewScoped in Mojarra as well)
>
>
> > then every time a new request starts, this event is fired which causes an
> > instance of the bean to be created for that request?
>
> Yes, that is what this does ;)
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Aug 2015 23:16:27 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> wrote:
> > Someone over on the JMS user alias told me about this yesterday. So that
> > would avoid the need to call a method to trigger lazy initialisation on
> > normal-scoped bean proxies. I presume the application still has to inject
> > the bean.
>
> The bean does not necessarily have to be injected at any point.
>
> With @Eager it will be activated and its @PostConstruct method will be
> invoked in case it hadn't been referenced before (which in case of
> @Eager is unlikely, as it instantiates very early, but still
> theoretically possible).
>
> The bean can of course still be injected or otherwise referenced later
> within the same scope, but as mentioned this is not required.
>
> So for example if you have OmniFaces on your classpath and then only
> the following bean in an application:
>
> @Eager
> @ApplicationScoped
> public class MyEagerApplicationScopedBean {
>
> @PostConstruct
> public void init() {
> System.out.println("Application scoped init!");
> }
> }
>
> Then you'll see "Application scoped init!" being printed in your
> server log when you deploy that application. No other code is needed.
>
>
> > If so then it sounds useful. Is it going to be included as a standard
> > feature of CDI 2.0? I see someone has proposed
> > https://issues.jboss.org/browse/CDI-473 .
>
> As the issue already mentions, this is possible with current day CDI
> already. The proposal may arguably make it a little more concise and a
> little less verbose. An eager attribute on the scope looks like a
> quite minimal and elegant solution. Additionally it may make sense for
> some scopes to restrict for which "IDs' it's eagerly instantiated
> (e.g. paths for @RequestScoped, view IDs for @ViewScoped, flow IDs for
> @FlowScoped, etc).
>
> A new @Startup seems more like a very specific usage of the eager
> attribute, namely for @ApplicationScoped (or Singleton?) beans.
>
> Kind regards,
> Arjan
>
>
>
>
>
> >
> > Nigel
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Aug 2015 10:11:21 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=
> SyQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
>
> > Hi,
> >
> > On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin(a)oracle.com>
> > wrote:
> > > On 25/08/2015 12:38, arjan tijms wrote:
> > > This looks very interesting. Does this work with any normal scope?
> >
> > Yes, all normal scopes that are available in standard Java EE support
> > this as far as I know.
> >
> >
> Events are not mandatory for a normal scope - at least was the case in 1.2
> - so JMS can't rely on it for custom normal scopes.
>
>
> > There's the small caveat that CDI itself doesn't know about this
> > automatically for any custom normal scope. That implementation of such
> > scope (via a Context) must explicitly throw these events.
> >
> > For example, this is what Mojarra does for the @FlowScoped
> implementation:
> >
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> >
> > Which is fired when the scope starts here:
> >
> >
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com...
> >
> > (the exact same code is used for @ViewScoped in Mojarra as well)
> >
> >
> > > then every time a new request starts, this event is fired which causes
> an
> > > instance of the bean to be created for that request?
> >
> > Yes, that is what this does ;)
> >
> > Kind regards,
> > Arjan Tijms
> > _______________________________________________
> > 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/20150826/c1f05f1c/at...
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Aug 2015 10:07:01 +0100
> From: Nigel Deakin <nigel.deakin(a)oracle.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <55DD81B5.9040407(a)oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> (Tidying up the top-posting...)
>
> Romain Manni-Bucau:
> > ...I see it really nice to not rely only on annotation - and aligned
> with
> > most specs - since sometimes you just want to either be able to rely on
> a
> > loop or a custom config to register your listeners. Annotations are too
> > rigid for such cases.
>
> Nigel:
> > Obviously, if users don't want to use CDI (or MDBs, which are also
> > declarative), then they would use the normal JMS API. The existing
> > API to register an async message listener isn't good enough,
> > and we may improve it in JMS 2.1, but that's not something that
> > I'd want to bother the people on cdi-dev with.
>
> Romain Manni-Bucau:
> > Integrating it in CDI lifecycle through an event allow CDI users to
> still
> > use it in the right phase of the container boot so it is still important
> > IMO and avoid all users to have their own custom listener for it -
> > @Initialized(AppScoped.class). Also allow to enrich the API through the
> event
> > itself making things smoother IMO.
>
> Nigel:
> > I'm sorry I don't understand you.
> > I thought you were asking about an API which does not use annotation.
>
> Romain Manni-Bucau:
> > Both are needed (like websocket spec). Annotation one is nice for fully
> business
> > code and/or simple libs but relying on CDI allows to simplify the
> wiring since you
> > can reuse CDI beans under the hood ie have an implicit connection
> factory if
> > there is a single one etc which is not possible in fully SE context.
>
> Can you explain the distinction you're making here? You seem to be
> suggesting two alternatives, using "annotation" and
> "relying on CDI". What would an application which uses CDI but which
> doesn't use annotation look like?
>
> Nigel
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Aug 2015 11:07:46 +0200
> From: arjan tijms <arjan.tijms(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE=-
> AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau(a)gmail.com> wrote:
> >> Yes, all normal scopes that are available in standard Java EE support
> >> this as far as I know.
> >>
> >
> > Events are not mandatory for a normal scope - at least was the case in
> 1.2 -
> > so JMS can't rely on it for custom normal scopes.
>
> Absolutely true, but that was exactly what I said ;)
>
> All Java EE provided scopes throw the events. For CDI, this is
> mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> @ApplicationScoped and @ConversationScoped.
>
> For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> have to double check whether this is actually in the spec for those
> last two and if not see if we can update it for 2.3.
>
> Kind regards,
> Arjan Tijms
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 Aug 2015 11:09:30 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: arjan tijms <arjan.tijms(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=
> kL6gyb5jHb7fdA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
>
> > Hi,
> >
> > On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> > <rmannibucau(a)gmail.com> wrote:
> > >> Yes, all normal scopes that are available in standard Java EE support
> > >> this as far as I know.
> > >>
> > >
> > > Events are not mandatory for a normal scope - at least was the case in
> > 1.2 -
> > > so JMS can't rely on it for custom normal scopes.
> >
> > Absolutely true, but that was exactly what I said ;)
> >
> > All Java EE provided scopes throw the events. For CDI, this is
> > mandated by the spec (6.7) for @RequestScoped, @SessionScoped,
> > @ApplicationScoped and @ConversationScoped.
> >
> > For JSF, at least Mojarra, @FlowScoped and @ViewScope do so too. I
> > have to double check whether this is actually in the spec for those
> > last two and if not see if we can update it for 2.3.
> >
> >
> Agree for provided scope but JMS + short time scopes will not match well in
> practise so i would worry more about not "default" scopes which can miss
> these events.
>
>
> > Kind regards,
> > Arjan Tijms
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/a7884300/at...
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Aug 2015 11:16:04 +0200
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] JMS 2.1: Proposal to allow any CDI managed bean
> in a Java EE application to listen for JMS messages
> To: Nigel Deakin <nigel.deakin(a)oracle.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=
> 7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin(a)oracle.com>:
>
> > (Tidying up the top-posting...)
> >
> > Romain Manni-Bucau:
> > > ...I see it really nice to not rely only on annotation - and aligned
> with
> > > most specs - since sometimes you just want to either be able to rely
> on a
> > > loop or a custom config to register your listeners. Annotations are too
> > > rigid for such cases.
> >
> > Nigel:
> > > Obviously, if users don't want to use CDI (or MDBs, which are also
> > > declarative), then they would use the normal JMS API. The existing
> > > API to register an async message listener isn't good enough,
> > > and we may improve it in JMS 2.1, but that's not something that
> > > I'd want to bother the people on cdi-dev with.
> >
> > Romain Manni-Bucau:
> > > Integrating it in CDI lifecycle through an event allow CDI users to
> still
> > > use it in the right phase of the container boot so it is still
> important
> > > IMO and avoid all users to have their own custom listener for it -
> > > @Initialized(AppScoped.class). Also allow to enrich the API through the
> > event
> > > itself making things smoother IMO.
> >
> > Nigel:
> > > I'm sorry I don't understand you.
> > > I thought you were asking about an API which does not use annotation.
> >
> > Romain Manni-Bucau:
> > > Both are needed (like websocket spec). Annotation one is nice for fully
> > business
> > > code and/or simple libs but relying on CDI allows to simplify the
> wiring
> > since you
> > > can reuse CDI beans under the hood ie have an implicit connection
> > factory if
> > > there is a single one etc which is not possible in fully SE context.
> >
> > Can you explain the distinction you're making here? You seem to be
> > suggesting two alternatives, using "annotation" and "relying on CDI".
> What
> > would an application which uses CDI but which doesn't use annotation look
> > like?
> >
> >
> The sample I gave before with the JmsStart event basically:
>
>
> public class JmsRegistrar {
> @Inject
> @JmsConnectionFactory(...)
> private ConnectionFactory factory;
>
> @Inject
> @JmsQueue(...)
> private Queue queue;
>
> public void startJms(@Observes JmsStart start) {
> start.withFactory(factory) // withFactory should be optional if
> only 1 bean matches it
> .register(MyCdiTypedListener.class) // with defaults for all
> potential config
> .listenOn(queue)
> .register(MyCdiTypedListener2.class, new MyLiteral())
> .withMaxSessions(10)
> .listenOn(Queue.class, new QueueLiteral(...))
> ......;
> }
> }
>
>
> The power of it appears when you have a config injection in JmsRegistrar
> you can iterate over to get the list of listener for instance.
>
> Also JMS resources can be decorated and referenced from qualifiers instead
> of instances thanks to CDI.
>
> It doesnt prevent the app to use @JmxListener somewhere else if the
> listener doesnt need any input/config to be registered.
>
>
> > Nigel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150826/cb5c6600/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 57, Issue 21
> ***************************************
>
9 years, 6 months
- 1
- 0
[JBoss JIRA] (CDI-555) Inaccurate wording in "24.3.1. Obtaining a reference to the CDI container in Java EE"
by Tomas Remes (JIRA)
Tomas Remes created CDI-555:
-------------------------------
Summary: Inaccurate wording in "24.3.1. Obtaining a reference to the CDI container in Java EE"
Key: CDI-555
URL: https://issues.jboss.org/browse/CDI-555
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 2.0-EDR1
Reporter: Tomas Remes
Chapter {{24.3.1. Obtaining a reference to the CDI container in Java EE}} states:
{quote}
When running in Java EE, when initialize, stop or shutdown methods of CDIProvider are called an UnsupportedOperationException is thrown.
{quote}
However there are no shutdown and stop methods in {{javax.enterprise.inject.spi.CDIProvider}} interface
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
- 1
- 0