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
>