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@lists.jboss.org> wrote:
Send cdi-dev mailing list submissions to
        cdi-dev@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@lists.jboss.org

You can reach the person managing the list at
        cdi-dev-owner@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@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@oracle.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CAE=-AhCnTyS-ZVAfT9k2jDK=k6QHW4ShUab_Vt+e6WmBN76gWg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin@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/sun/faces/flow/FlowCDIEventFireHelperImpl.java

Which is fired when the scope starts here:
https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431

(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@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@oracle.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CAE=-AhCugW3jWD1FnghFzAkiuBL6-Kg2ROKa2FCJHfcd2E2+DQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

On Tue, Aug 25, 2015 at 7:20 PM, Nigel Deakin <nigel.deakin@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@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@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CACLE=7PQaDz4fmXW2f39PN_+zdXioDfAu987OSuaxodBZx=SyQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2015-08-25 22:53 GMT+02:00 arjan tijms <arjan.tijms@gmail.com>:

> Hi,
>
> On Tue, Aug 25, 2015 at 7:07 PM, Nigel Deakin <nigel.deakin@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/sun/faces/flow/FlowCDIEventFireHelperImpl.java
>
> Which is fired when the scope starts here:
>
> https://github.com/omnifaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/flow/FlowCDIContext.java#L431
>
> (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@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/attachment-0001.html

------------------------------

Message: 4
Date: Wed, 26 Aug 2015 10:07:01 +0100
From: Nigel Deakin <nigel.deakin@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@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID: <55DD81B5.9040407@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@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@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CAE=-AhBcnrC6xOdRSXtBdg-7JgfcKcGQMgtow4V0PPVspKxr_Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi,

On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
<rmannibucau@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@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@gmail.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CACLE=7NfLo0ZXvSG2Ae1mLRd2kGWWjmr6E0=kL6gyb5jHb7fdA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2015-08-26 11:07 GMT+02:00 arjan tijms <arjan.tijms@gmail.com>:

> Hi,
>
> On Wed, Aug 26, 2015 at 10:11 AM, Romain Manni-Bucau
> <rmannibucau@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/attachment-0001.html

------------------------------

Message: 7
Date: Wed, 26 Aug 2015 11:16:04 +0200
From: Romain Manni-Bucau <rmannibucau@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@oracle.com>
Cc: cdi-dev <cdi-dev@lists.jboss.org>
Message-ID:
        <CACLE=7O3b8WM79ueUcmuDq5Vi_UC5o2gObU8MnK8tqGJMcGfOQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2015-08-26 11:07 GMT+02:00 Nigel Deakin <nigel.deakin@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/attachment.html

------------------------------

_______________________________________________
cdi-dev mailing list
cdi-dev@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
***************************************