Reza,
Reza Rahman wrote:
> Marina,
>
> Since any sensible managed bean method could potentially be an
> asynchronous message receiver via @Listens, you could indeed have more
> than one "onMessage" methods for a bean. I think this enhances
> flexibility and usability in important ways for developers.
>
> Honestly, I wasn't thinking much about the current EJB component model
> at all, but I don't see why SLSBs and Singletons could not have
> @Listens methods too (the SFSB case would be trickier). The real goal
> in my mind is really to unlock the messaging services from a special
> purpose component so that they are more generally available/usable
> across all Java EE components. As a side-effect, we would discourage
> further use of @MessageDriven and conceivably deprecate it one day.
May be yes, may be not... Having a dedicated bean for message
consumption can be useful with bean/thread pooling setup...
>
> Just imagine how much more usable/OO-centric this could be. You could
> have things like this:
>
> public class OrderService {
> ...
> @Listens
> @JmsDestination("jms/OrderQueue")
> public void processOrder(Order order) {
> ...
> }
> ...
> @Listens
> @JmsDestination("jms/CancellationQueue")
> public void cancelOrder(Order order) {
> ...
> }
> ...
> }
>
> Now, strictly speaking, you could remove the need to have @Listens and
> simply process messages if we see @JmsDestination,
> @ActivationConfigProperty, etc but I think it would be an actual net
> reduction in readability (kind of the same thing as omitting the
> @Inject annotation in the early versions of CDI).
I'm not sure @Listens adds readability, but I'd be interested in what
others think...
> If you are asking why we could not literally have multiple "onMessage"
> methods, the issue of course is that Java will not allow you to have
> more than one method with the same signature (I very much doubt that's
> what you are asking me, but I'm just making sure).
I just meant the method with "onMessage" functionality, like a timeout
method. If we go this route, we'd need to come up with a good name for
those methods.
Best,
-marina
>
> Cheers,
> Reza
>
>
> On 9/27/2011 8:23 PM, Marina Vatkina wrote:
>> Expanding on your @ActivationConfigProperty example below, can we
>> allow MDBs to have more than one "onMessage" method (why would it
>> also need @Listens annotation?)? How about allowing SLSB to define
>> such methods via @ActivationConfigProperty's?
>>
>> -marina
>>
>> Reza Rahman wrote:
>>> It's a bit of both. However, you really can't make this
>>> functionality available for all managed beans without leaving the
>>> older component model behind...
>>>
>>> On 9/27/2011 4:49 PM, Rick Hightower wrote:
>>>> +1 for both.
>>>> On Tue, Sep 27, 2011 at 11:45 AM, Pete Muir
>>>> <pmuir_at_bleepbleep.org.uk <mailto:pmuir_at_bleepbleep.org.uk>> wrote:
>>>>
>>>> I see. How about if used the same API we have today for MDBs but
>>>> made it available as managed beans?
>>>>
>>>> What I'm trying to split out is whether you are primarily
>>>> interested in making this available outside of EJBs OR you want
>>>> to fix a broken API (or BOTH).
>>>>
>>>> On 27 Sep 2011, at 18:31, reza_rahman_at_lycos.com
>>>> <mailto:reza_rahman_at_lycos.com> wrote:
>>>>
>>>> > The MDB refactoring part I see as just another facet of moving
>>>> away from the dated EJB component model.
>>>> >
>>>> > Sep 27, 2011 07:59:32 AM, jsr345-experts_at_ejb-spec.java.net
>>>> <mailto:jsr345-experts_at_ejb-spec.java.net> wrote:
>>>> > Thanks!
>>>> >
>>>> > Looks like John is going to revive this on the JMS EG. I'm on
>>>> the observers list now, so can take a look at the issues you
>>>> faced and see if we can't simply enhance the CDI events to cope
>>>> (additionally, we've already enhanced the events system in a
>>>> number of small ways which may help).
>>>> >
>>>> > My main concern with the approach here is that invents a new
>>>> API for something we already have defined (MDBs) and I think we
>>>> need to be very careful of reinventing just because we can...
>>>> >
>>>> > On 27 Sep 2011, at 01:17, Reza Rahman wrote:
>>>> >
>>>> > > Pete,
>>>> > >
>>>> > > There is an old thread on this you can revive for the JMS 2
>>>> EG. I believe it was initiated by Rudiger in relation to his JMS
>>>> abstraction API some months ago. It certainly won't hurt to
>>>> rehash this again. The MDB issue was also discussed - the end
>>>> result is really this thread (which is not at all a bad thing)
>>>> :-).
>>>> > >
>>>> > > Cheers,
>>>> > > Reza
>>>> > >
>>>> > >
>>>> > > On 9/26/2011 2:50 PM, Pete Muir wrote:
>>>> > >> At the very least, I would appreciate feedback from the JMS
>>>> EG on where the mapping falls down so we can enhance the CDI API
>>>> as needed.
>>>> > >>
>>>> > >> On 26 Sep 2011, at 19:43, Pete Muir wrote:
>>>> > >>
>>>> > >>> Interesting, I wasn't aware of this discussion/conclusion,
>>>> and would be interested to read more about it.
>>>> > >>>
>>>> > >>> I suppose my next favorite approach is to offer MDBs
>>>> outside of the EJB container, than invent an entirely new API for
>>>> it. Have you guys considered that?
>>>> > >>>
>>>> > >>> On 26 Sep 2011, at 18:34, reza_rahman_at_lycos.com
>>>> <mailto:reza_rahman_at_lycos.com> wrote:
>>>> > >>>
>>>> > >>>> Pete,
>>>> > >>>>
>>>> > >>>> We actually discussed this in the JMS 2 EG in relative
>>>> detail. I know it's very tempting to think about CDI events and
>>>> JMS messages as being synonymous (the similarities are obvious).
>>>> The problem is that the current set of JMS features do not map
>>>> very well to CDI events. It isn't as obvious when you look at
>>>> asynchronous message receipt in particular (as we are here). The
>>>> feature loss is more obvious when for example we start discussing
>>>> sending JMS messages. Now, if the features/flexibility lost were
>>>> corner cases anyway, it would not be a big deal. The issue is
>>>> that the JMS features potentially lost are frequently used in the
>>>> real world today.
>>>> > >>>>
>>>> > >>>> I think it's best to keep the CDI Event/JMS bridge as a
>>>> non-standard portable extension (a la Seam JMS) and think about
>>>> CDI events and JMS messages as orthogonal concerns from a Java EE
>>>> standpoint (just as it is today). The other way of doing this
>>>> would be to try to enhance CDI events to match the JMS model
>>>> more. I don't think that would be a sensible thing to do for the
>>>> simple reason that these really are very different concerns.
>>>> > >>>>
>>>> > >>>> Hope this makes sense - I can understand that this is
>>>> probably not the response you want to really hear...
>>>> > >>>>
>>>> > >>>> Cheers,
>>>> > >>>> Reza
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> Sep 26, 2011 12:59:10 PM, jsr345-experts_at_ejb-spec.java.net
>>>> <mailto:jsr345-experts_at_ejb-spec.java.net> wrote:
>>>> > >>>> Reza,
>>>> > >>>>
>>>> > >>>> Would you like to see this instead of, as well as, or not
>>>> as much as, a bridge from JMS to CDI events?
>>>> > >>>>
>>>> > >>>> On 26 Sep 2011, at 01:12, Reza Rahman wrote:
>>>> > >>>>
>>>> > >>>>> Marina,
>>>> > >>>>>
>>>> > >>>>> Sorry it took so long to respond to this. It's been a
>>>> crazy couple of weeks :-(.
>>>> > >>>>>
>>>> > >>>>> As I mentioned previously, the basic idea is to separate
>>>> asynchronous message processing from the current MDB component
>>>> model. So, in a newer model, any Java EE managed bean (including
>>>> perhaps a Servlet) could receive a JMS asynchronous message like
>>>> this:
>>>> > >>>>>
>>>> > >>>>> public class SomeBean {
>>>> > >>>>> ...
>>>> > >>>>> @Listens
>>>> > >>>>> @JmsDestination("jms/SomeQueue")
>>>> > >>>>> @JmsConnectionFactory("jms/ConnectionFactory")
>>>> > >>>>> @JmsSessionMode(AUTO_ACKNOWLEDGE)
>>>> > >>>>> @JmsMessageSelector("foo=bar")
>>>> > >>>>> public void someMethod(Message message) {
>>>> > >>>>> ...
>>>> > >>>>> }
>>>> > >>>>> ...
>>>> > >>>>> }
>>>> > >>>>>
>>>> > >>>>> Because this would be loosely modeled after CDI/DI, the
>>>> message receiver method parameters could be quite powerful. So we
>>>> could do things like this:
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(MyMessage message) {
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(String message) {
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(byte[] message) {
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(Map message) {
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(MyMessage message,
>>>> > >>>>> @JmsCorrelationId String correlationId,
>>>> > >>>>> @JmsReplyTo Destination destination,
>>>> > >>>>> @JmsProperty("myProperty") int someProperty) {
>>>> > >>>>>
>>>> > >>>>> @Listens
>>>> > >>>>> public void someMethod(Message message, @Inject
>>>> SomeOtherBean otherBean) {
>>>> > >>>>>
>>>> > >>>>> Because such listener methods need to be transactional,
>>>> it's difficult to go too far with this without decoupling
>>>> declarative transactions from the EJB component model. It's also
>>>> the case that things like concurrency must be figured out for
>>>> this model (perhaps by decoupling @Lock from EJB or defining
>>>> @PoolScoped, @TransactionScoped or @MaxConcurrency). Besides
>>>> enabling messaging for non-EJB components, this enhancement would
>>>> also enable us to treat JMS with first-class citizen semantics
>>>> and move away from the over-generalized JCA based semantics that
>>>> we have today. We could also similarly support a JCA based model
>>>> like this:
>>>> > >>>>>
>>>> > >>>>> public class SomeBean {
>>>> > >>>>> @Listens
>>>> > >>>>> @ActivationConfigProperty(propertyName="mailServer",
>>>> propertyValue="mailHost"),
>>>> > >>>>> @ActivationConfigProperty(propertyName="mailFolder",
>>>> propertyValue="INBOX"),
>>>> > >>>>> @ActivationConfigProperty(propertyName="storeProtocol",
>>>> propertyValue="imap"),
>>>> > >>>>> @ActivationConfigProperty(propertyName="userName",
>>>> propertyValue=""),
>>>> > >>>>> @ActivationConfigProperty(propertyName="password",
>>>> propertyValue="secret")
>>>> > >>>>> public void someMethod(Message message) {
>>>> > >>>>> ...
>>>> > >>>>> }
>>>> > >>>>> }
>>>> > >>>>>
>>>> > >>>>> Now, I think this is going to take quite a bit of work to
>>>> standardize, so I am not sure it is right for EJB 3.2. Also, I
>>>> think we should go down this path after the current JMS 2
>>>> discussion of a higher-level dependency injection based API is
>>>> resolved. For example, we may be able to re-use some of the
>>>> annotations being developed as part of that API. Also, any new
>>>> JMS related annotations could be defined in javax.jms rather than
>>>> javax.ejb. Similarly, I wonder if the JCA listener related
>>>> annotations really belong in javax.resource?
>>>> > >>>>>
>>>> > >>>>> Note, I don't think any of this need be bound directly to
>>>> CDI or CDI events per se, although I can see us using some JSR
>>>> 330 annotations and underlying implementations using the CDI
>>>> portable extension SPI (in a relatively container specific
>>>> manner).
>>>> > >>>>>
>>>> > >>>>> Hope it helps. Let me know if I need to explain anything
>>>> in greater detail. I have kept this brief and high-level on
>>>> purpose.
>>>> > >>>>>
>>>> > >>>>> Cheers,
>>>> > >>>>> Reza
>>>> > >>>>>
>>>> > >>>>>
>>>> > >>>>> On 9/12/2011 6:21 PM, Marina Vatkina wrote:
>>>> > >>>>>> Reza,
>>>> > >>>>>>
>>>> > >>>>>> There is a plan (stay tuned) to make CMTs available
>>>> outside EJBs. But how does it affect MDBs in the EJB container?
>>>> > >>>>>>
>>>> > >>>>>> thanks,
>>>> > >>>>>> -marina
>>>> > >>>>>>
>>>> > >>>>>> Reza Rahman wrote:
>>>> > >>>>>>> Marina,
>>>> > >>>>>>>
>>>> > >>>>>>> I think it's hard to have this discussion without
>>>> starting to talk about decoupling transactions (and other
>>>> services) from the EJB component model. Did you still want to
>>>> have this discussion now?
>>>> > >>>>>>>
>>>> > >>>>>>> Cheers,
>>>> > >>>>>>> Reza
>>>> > >>>>>>>
>>>> > >>>>>>>
>>>> > >>>>>>> On 9/9/2011 9:11 PM, Marina Vatkina wrote:
>>>> > >>>>>>>> Experts,
>>>> > >>>>>>>>
>>>> > >>>>>>>> Does any of you have a wish-list for the MDB
>>>> improvements in the EJB spec? This should be a purely EJB related
>>>> changes, as the JMS 2.0 EG is looking carefully at the overall
>>>> JMS revamp.
>>>> > >>>>>>>>
>>>> > >>>>>>>> thanks,
>>>> > >>>>>>>> -marina
>>>> > >>>>>>>>
>>>> > >>>>>>>>
>>>> > >>>>>>>>
>>>> > >>>>>>>> -----
>>>> > >>>>>>>> No virus found in this message.
>>>> > >>>>>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> > >>>>>>>> Version: 10.0.1392 / Virus Database: 1520/3886 -
>>>> Release Date: 09/09/11
>>>> > >>>>>>>>
>>>> > >>>>>>>>
>>>> > >>>>>>
>>>> > >>>>>> -----
>>>> > >>>>>> No virus found in this message.
>>>> > >>>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> > >>>>>> Version: 10.0.1392 / Virus Database: 1520/3893 - Release
>>>> Date: 09/12/11
>>>> > >>>>>>
>>>> > >>>>>>
>>>> > >>
>>>> > >>
>>>> > >> -----
>>>> > >> No virus found in this message.
>>>> > >> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> > >> Version: 2012.0.1809 / Virus Database: 2085/4519 - Release
>>>> Date: 09/25/11
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Rick Hightower*
>>>> (415) 968-9037
>>>> Profile <http://www.google.com/profiles/RichardHightower>
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com <http://www.avg.com>
>>>> Version: 2012.0.1809 / Virus Database: 2085/4521 - Release Date:
>>>> 09/26/11
>>>>
>>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1809 / Virus Database: 2085/4523 - Release Date:
>> 09/27/11
>>
>>
>