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