+1 for both.
On Tue, Sep 27, 2011 at 11:45 AM, Pete Muir <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 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 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 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 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
> > >>>>>>>> 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
> > >>>>>> 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
> > >> 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>