Nigel,
On Tue, Mar 12, 2013 at 8:27 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> Community member "genomeprjct" logged this JIRA issue. This is a proposal
> that JMS takes advantages of the JCA and EJB changes described in the
> recent email by Bill Shannon that I forwarded recently.
>
>
I thought we had previously noted that this user was in fact a member of
the E.G.? A member who likely laments that the one piece of information
that absolutely cannot be changed is his old Project Kenai username which
has been imported to the java.net JIRA?
> Here is the genomeprjct's proposal. I'll respond in a follow-up email.
>
> ------------------------------**------------------------------**
> ------------------------------**--------------------
> Take advantage of EJB 3.2's RA improvement for MDBs
> ------------------------------**----------------------
>
> Key: JMS_SPEC-116
> URL: http://java.net/jira/browse/**JMS_SPEC-116<http://java.net/jira/browse/JMS_SPEC-116>
> Project: jms-spec
> Issue Type: New Feature
> Reporter: genomeprjct
>
>
> In a late change to the EJB 3.2 spec, a new feature around building MDBs
> without requiring method-level implementations has been added, specifically
> for use within the RA.
>
> I am proposing that the JMS spec take advantage of this new feature in the
> following ways:
>
> The description references this email thread from the EJB Spec:
> http://java.net/projects/ejb-**spec/lists/jsr345-experts/**
> archive/2013-03/message/49<http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2013-03/message/49>
>
> 1. Introduce a new interface "javax.jms.JMSMessageEndpoint" (or similar
> name) that can be used as a marker interface required by
> MessageEndpointFactory.**getEndpointClass(). It shall have no methods,
> not extend any other interface but simply exist to be a marker that the
> given class will have its public methods exposed as potential targets for
> messages received by the RA.
>
> 2. Introduce a new annotation, or possibly several annotations, to
> represent the configuration available to these methods. I believe we
> should support something more fluid (e.g. compiler friendly) than the
> existing ActivationConfigProperty set.
>
> 3. Currently, the onMessage method is defined by looking for a method
> named "onMessage" that takes a "Message" object as an argument. This
> algorithm should be changed to also look for any instance of
> "JMSMessageEndpoint", find any method that is annotated as XXX (whatever is
> defined in 2) as a possible target, then depending on there being a match
> between that takes anything that derives from "Message" and only pass
> appropriate messages to it.
>
> Some down sides:
>
> 1. The EG has already voted to not require an RA with every implementation.
> 2. This is a late change, so is the EJB equivalent.
> 3. Currently, MDB behavior and RA aren't necessarily defined within the
> JMS spec.
>
> ------------------------------**------------------------------**
> ------------------------------**--------------------
>
> I think it unfortunate that this change has
>
>
I think your email was cut off here, but you were likely going to say that
this is too late for the JMS 2.0 EG to take for action.
I personally believe we should be taking cues from the EJB and the Platform
specs and at least have an answer for it in JMS 2.0. Based on the feedback
I've seen from David Blevins, this is more or less a compromise based on
size to be able to fit in to the current release.
I don't believe anything that was proposed was too substantial, especially
since we don't require a JMS provider to even provide a Resource Adapter,
it is only recommended at this point (pg 108, PFD).
John