I like Jasper's proposal of using a special JmsActivationSpec, and which seems should be defined in JMS SPEC.
Furthermore, we may consider to move all JMS related new features including CONNECTOR_SPEC-4 to this class:
public interface JmsActivationSpec extends ActivationSpec {
public String getActivationUniqueName();
public void setActivationUniqueName(String v);
public String getInstanceName();
public void setInstanceName(String name);
public Destination getDestination();
public void setDestination(Destination destination);
public ConnectionFactory getConnectionFactory();
public void setConnectionFactory(ConnectionFactory cf);
... // anything required by JMS adapter
}
These new properties are all used by JMS adapter only at least in this moment and I am not sure they make sense for other adapters.
Since it is MDB container, when Endpoint application is MDB, that is responsible for setup correct values for ActivationSpec, it would be nature to require MDB container to do lookup in its namespace based on destinationLookup/connectionFactoryLookup before pass the ActivationSpec instance to endpointActivation call. Adapters will no longer required to do JNDI lookup anymore.
Furthermore, IIUC, Endpoint applications do NOT necessarily mean MDB; they may be non-MDB as long as AS supports and this is allowed by Connector 1.6 SPEC. Non-MDB Endpoint applications may or may not have java:comp namespaces. Therefore we'd better not put hard requirement on this in Connector SPEC.
By moving these method to JmsActivationSpec, Endpoint application providers, no matter MDB container or anything else, are free to use its own solution to provide those objects based on destinationLookup/connectionFactoryLookup values.
Thanks
Wilson
> -----Original Message-----
> From: Jesper Pedersen [mailto:jesper.pedersen_at_redhat.com]
> Sent: Thursday, December 06, 2012 3:22 AM
> To: jsr322-experts_at_connector-spec.java.net
> Subject: [jsr322-experts] Re: JMS RA requirements (Discussion on CONNECTOR_SPEC-1 and CONNECTOR_SPEC-5)
>
> Hi,
>
> On 12/05/2012 01:38 PM, Sivakumar Thyagarajan wrote:
> > We could remove Appendix B, and instead provide a pointer to the JMS
> > spec (Chapter 12) for more information on JMS RA configuration.
> >
> > I have raised a JIRA issue CONNECTOR_SPEC-5 to track this.
> >
> > QUESTION: Is the group ok with this removal of Appendix B from the spec?
> >
>
> Agreed.
>
> >
> > JMS 2.0 adds 2 new features (that are discussed below in 2(a) and
> > 2(b)) and they are discussed in detail in:
> > * the JMS spec chapter 12 (which defines the behaviour of a JMS RA)
> > [2]
> > * the EJB 3.2 spec [3] 5.4.16.7 and 5.4.16.9 (which define the
> > behaviour of a JMS MDB which doesn't use Connectors).
> >
> > 2.(a) Allowing Topic subscription names to be left unset by the bean
> > deployer: This is an ease of use feature, as most users simply set the
> > subscription name to the name of the MDB manually, and this could be
> > automated through a contract between the container and the RA.
> >
> > [As a refresher, the definitions of Topic Subscriptions,
> > Durable/Non-Durable, Shared/Non-Shared subscriptions are in Section
> > 6.3 and 6.11 of [2]].
> >
> > To support 2.(a), there is a proposal from Nigel Deakins in
> > CONNECTOR_SPEC-1 to enhance the MessageEndpointInterface to add a new
> > method to provide the MessageEndpoint's name to the RA, and suggests
> > the requirements on the MDB container's implementation of this method.
> >
> > Though some of the requirements appear to be JMS-specific, this method
> > and the proposed javadoc requirements are written in a generic way so
> > that it could be used by all RAs.
> >
> > A JMS RA would then be able to use this during endpointActivation to
> > determine the unique MDB name that is being activated while
> > generating the JMS topic subscription name. The current proposed name
> > is MessageEndpointFactory.getEndpointUniqueName(), but I would like it
> > to be modified to getActivationUniqueName() as we are talking about
> > the unique name for the Activation in the application server.
> >
> > QUESTION: What do you think? Any other choice for the method name?
> > Is the group fine with the proposed javadoc requirements for the method?
> >
>
> The activation is based on the ActivationSpec, so why not do
>
> package javax.jms.ra;
>
> public interface JmsActivationSpec extends ActivationSpec {
> public String getActivationUniqueName();
> public void setActivationUniqueName(String v); }
>
> ?
>
> Yes, it would make the contract more loose, but the whole area is pretty loose anyway. The component (f.ex. MDB
> container) creating the MessageEndpointFactory would detect that it is a JmsActivationSpec instance and fill out
> the values needed.
>
> > 2.(b) allowing Topic subscriptions to be shared or not shared across a
> > cluster.
> >
>
> As above, with the additional information needed.
>
> Best regards,
> Jesper
>