Hi John,
On 3/11/13 4:07 AM, John D. Ament wrote:
> Hi Marina,
>
> Thanks for the response. Thank you for clarifying why we cannot use
> CDI observers here, makes sense (though I'll always be disappointed).
> Based on David's doc, it seems like the annotation on the message
> listener method plays a significant role. How can the container
> manage a method that has no clear use (no annotation present)? Should
> the container ignore it, or throw a deployment exception?
The container lets RA do it. The RA will introspect the class and find
all metadata that it needs, or it can just introspect the MDB class and
based on the bean method signatures decide which methods to call.
>
> Regarding ownership then, since @MessageDriven is owned by the EJB
> spec today, which spec should define the annotation on the message
> listener method specific to a JMS Resource Adapter?
Probably the JCA spec should say that a RA can define annotations as
part of its contract (I'll talk to the JCA spec lead).
> Note that even requiring a RA in the JMS Provider was voted down by
> the EG earlier this year (a reversal of a previous decision to include
> it).
I know.
thanks,
-marina
>
> John
>
>
> On Mon, Mar 11, 2013 at 12:49 AM, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Hi John,
>
>
> On 3/9/13 5:01 PM, John D. Ament wrote:
>> Hi Marina, David,
>>
>> So first, understand that my sentiments are mine, they do not
>> represent JSR-343 as a whole, but do represent my opinion as a
>> member of that EG as well as a strong user of EE tech like EJB & CDI.
>>
>> For the sake of my opinion, I'm going to speak in context to the
>> JMS MDB, which currently implements javax.jms.MessageListener
>> that has a single onMessage method.
>>
>> In my opinion, this is a good proposal. I think what it's saying
>> is that we can define a message listener that is essentially a
>> marker interface, and instead of having to implement a specific
>> method in the existing interface and simply bind the methods in
>> the implemented MDB to "commands" that are understood by the RA.
>> For example, we could introduce a @ListensTo("jms/SomeQueue")
>> "command" method that could be placed on any method, perhaps
>>
>> @ListensTo("jms/SomeQueue")
>> public void handleSomeQueue(TextMessage tm) {
>> ..
>> }
>>
>> where only TextMessages are sent here that arrive on SomeQueue.
>> This is a giant step up in my opinion. We only need a single
>> class to handle all of the queues that an application developer
>> consumes from the container.
>
> Yes. That's exactly the case. The methods in the MDB will continue
> to be called "message listener methods", but all public methods
> will become those with the no-method message listener interface.
>
>
>>
>> What I don't like about this approach is that it introduces an
>> alternate way to handle events (since message listeners are
>> essentially event handlers) in the EE ecosystem. To me, this is
>> the functional equivalent of an ObserverMethod in CDI. Why
>> couldn't the RA look at observer methods to make the same
>> decision? Let's suppose that for semantics, instead of ListensTo
>> we have a different annotation, @EntriesOn(String) that is also a
>> CDI Qualifier. Then the method would be:
>>
>> public void handleSomeQueue(@Observes @EntriesOn("jms/SomeQueue")
>> TextMessage tm) {
>> ..
>> }
>>
>> Semantically this is very similar. However, I think this makes
>> the workload the RA easier and allows the runtime container to
>> work properly. The RA would not need to do reflection, instead
>> it would look for any new messages on the resource that it
>> monitors and convert them to a CDI event; firing that event into
>> the underlying application. CDI already handles this use case by
>> injecting additional arguments to your observer method if you
>> need them, in addition there was a sentiment in JSR-299 that MDBs
>> should be generating request scoped injections for these methods
>> (since request scope was ~~ thread local).
>
> This is a bigger change for the JCA spec, and as such is not
> possible for an MR release, and in particular that late in the
> release cycle. But now, that we are opening the RA for
> modifications, it can be a good candidate for EE 8 to look at.
>
> Best,
> -marina
>
>
>>
>> WDYT?
>>
>> John
>>
>>
>>
>> On Fri, Mar 8, 2013 at 10:53 PM, David Blevins
>> <david.blevins_at_gmail.com <mailto:david.blevins_at_gmail.com>> wrote:
>>
>> Of course I support this proposal :) See my comments on the
>> jsr342-experts@ thread for details:
>>
>> http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/2
>>
>> I want to give a special thanks to Marina, who has championed
>> this proposal internally, been a considerable advocate for us
>> and worked well beyond the normal point of no return for such
>> a significant change so late. As well, thank you to all the
>> supporters of this proposal in its various forms, both in
>> comments, votes, on the EG list and on the user list. We did
>> it! It's a real win for community action in the JCP.
>>
>> There will definitely be beers at JavaOne :)
>>
>> We've got just the right amount of functionality to give us
>> the most experience with this feature over the next 2 - 3
>> years and allow us the maximum flexibility and creativity for
>> Java EE 8.
>>
>>
>> -David
>>
>> On Mar 8, 2013, at 11:22 AM, Marina Vatkina
>> <marina.vatkina_at_oracle.com
>> <mailto:marina.vatkina_at_oracle.com>> wrote:
>>
>> > Experts,
>> >
>> > This is our chance at modernizing MDBs in the Java EE 7
>> release.
>> >
>> > Obviously at this late stage in the release, the approach
>> taken is to cause least disruption to all the specs (and the
>> Connector spec is already way in its MR process). So consider
>> it as the 1st step in the modernization process.
>> >
>> > Please review the proposed changes and voice your opinion
>> ASAP. You can reply here or on the Platform aliases.
>> >
>> > thanks,
>> > -marina
>> >
>> > -------- Original Message --------
>> > Subject: [javaee-spec users] [jsr342-experts] proposed
>> MDB improvements
>> > Date: Fri, 08 Mar 2013 11:11:40 -0800
>> > From: Bill Shannon <bill.shannon_at_oracle.com
>> <mailto:bill.shannon_at_oracle.com>>
>> > Reply-To: jsr342-experts_at_javaee-spec.java.net
>> <mailto:jsr342-experts_at_javaee-spec.java.net>
>> > To: jsr342-experts_at_javaee-spec.java.net
>> <mailto:jsr342-experts_at_javaee-spec.java.net>
>> >
>> > Expert group members,
>> >
>> > I need your feedback by Wednesday, March 13.
>> >
>> > David Blevins has proposed some changes to the Message
>> Driven Bean support:
>> >
>> > https://github.com/dblevins/mdb-improvements
>> >
>> > This Jira entry tracks this proposal:
>> >
>> > http://java.net/jira/browse/EJB_SPEC-60
>> >
>> > As you can see from the number of votes, this proposal has
>> received quite a
>> > bit of support, so we've been looking into what it would
>> take to implement
>> > it for Java EE 7.
>> >
>> > Given how late we are in the release, we need to carefully
>> manage the
>> > risk associated with such a change, and limit the scope
>> accordingly.
>> > At this point we have proposed spec changes and a prototype
>> implementation
>> > that we're comfortable with. I'd like to describe the spec
>> changes and
>> > get your feedback as to whether this is a reasonable and
>> safe addition
>> > to Java EE 7. It will be helpful to read David's
>> background proposal
>> > above.
>> >
>> >
>> > The first change is a minor addition to the Connectors spec:
>> >
>> > - Add a method to MessageEndpointFactory:
>> >
>> > /**
>> > * Return the Class object corresponding to the message
>> > * endpoint class. The resource adapter may use this to
>> > * introspect the message endpoint class to discover
>> > * annotations, interfaces implemented, etc. and modify
>> > * the behavior of the resource adapter accordingly.
>> > */
>> > public Class<?> getEndpointClass();
>> >
>> > This ability for the resource adapter to introspect the MDB
>> class
>> > seems useful independent of any other change, and it's a
>> simple,
>> > localized change to the Connector spec.
>> >
>> > This would require updating the in-progress Connector spec
>> Maintenance
>> > Review.
>> >
>> >
>> > The second change is a change to the EJB spec to require
>> that the
>> > MessageEndpointFactory.createEndpoint class behave
>> differently in
>> > certain situations. To support the use cases in David's
>> proposal,
>> > the resource adapter needs access to a proxy that
>> implements all of
>> > the public methods of the MDB class, not just the methods
>> of the
>> > message listener interface.
>> >
>> > The simple approach would be to require that the proxy
>> returned by
>> > the createEndpoint method always include all the public
>> methods, as
>> > well as implementing the message listener interface. That
>> change is
>> > too risky for this release.
>> >
>> > In the expected use cases, the resource adapter will use
>> reflection
>> > to invoke the methods of the MDB, based on annotations on
>> those methods.
>> > The message listener interface is unnecessary in these use
>> cases.
>> > Ultimately, we would like to remove the need for a message
>> listener
>> > interface, and provide another mechanism for associating an
>> MDB class
>> > with a resource adapter (e.g., based on annotations). That
>> too is too
>> > risky for this release.
>> >
>> > As a compromise, our proposal for now is this:
>> >
>> > - If the message listener interface has no methods, the EJB
>> container
>> > must provide a proxy returned from the createEndpoint
>> method that
>> > implements all the public methods of the MDB class, as
>> well as the
>> > message listener interface. (Perhaps that should be all
>> the public
>> > *business* methods, so that Object methods need not be
>> exposed?)
>> >
>> > This preserves the existing algorithm for associating a
>> resource
>> > adapter with an MDB, and redefines a currently useless case
>> to be useful.
>> > We can enhance this in a future release to provide more
>> flexible binding
>> > between an MDB and a resource adapter.
>> >
>> > If you think these changes are reasonable and it's
>> appropriate to add
>> > them to Java EE 7 at this late date, please speak up. As
>> usual we'll
>> > interpret silence as consent, but we'd greatly prefer to
>> have vocal
>> > support.
>> >
>> > And of course if you see any problems at all with this
>> proposal, I'm
>> > confident that you'll speak up immediately.
>> >
>> > Lacking serious issues or objections by Wednesday, March
>> 13, we'll
>> > proceed with this proposal.
>> >
>> > Thanks.
>> >
>> >
>> >
>>
>>
>
>