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