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.
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). 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).
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
>
>