Hi experts
We have had a lot of discussions on CONNECTOR_SPEC-1, and since we have a
fast approaching deadline, I would like us to close on this issue soon.
From our last EG meeting, we have already agreed [1] on
BootstrapContext.getUniqueId.
We appear to have three choices in the table, to consider for providing a
name of the activation to the RA:
- Choice 1: Original proposal: Introduce
MessageEndpointFactory.getActivationName, and have RA use them.
- Choice 2: Introduce a JMSActivationSpec in the JMS spec, and have the
spec that specifies the MEF (MDB/EJB spec) to state requirements on the
MEF implementation to handle JMSActivationSpec in a special manner (in
this case, have the MEF implementation set a JMSActivationSpec property
named activationName).
- Choice 3: Have the MDB container provide the activation's identifier in
JNDI (java:comp/UniqueMDBName or something similar) and have the RA lookup
this to get the activation name.
As a matter of API and architectural design, we want the Connector API to
be general. We also want the EJB MDB support (and as a side effect any
MEF implementations) to be general. We are trying to define APIs that are
not specific to JMS, even though JMS was the use case that drove the APIs.
This prevents us with going with Choice #2.
Choice #3, I have been advised recently, would not work in the cases of
MDBs-packaged-in-a-WAR scenario, where we would have all MDBs that are
part of a WAR share the java:comp namespace. [2]
One of the arguments against Choice #1, was that it placed a burden on MEF
implementations just for the JMS usecase.
In the context of Java EE, the AS vendor *is* the MEF vendor, and the cost
of implementing this is IMHO small, and hence this is not an extra burden.
For standalone connector containers that supports Message Inflow, it
should be possible to implement this easily as the MEF container there
would keep track of endpoint activations in some form (some 'identifier'
to represent an activation of a MessageEndpoint).
The current proposal for getActivationName strives to be not specific to
JMS, even though JMS was the use case that drove that API. One can
imagine that other resource adapters operating in a cluster might want to
have a cluster-wide unique name for an endpoint, as well as having a name
for each cluster instance (now available through BC.getUniqueId). Nothing
about the information that's provided by the AS vendor is JMS-specific.
So, I am leaning towards Choice #1. Could you please share your inputs on
this? Let us also discuss this in this week's call.
Thanks
--Siva.
[1]
http://java.net/projects/connector-spec/lists/jsr322-experts/archive/2013-01/message/34
[2] Section 15.4.2 and in
http://java.net/projects/ejb-spec/downloads/download/ejb-3_2-core-prd.pdf