Hi,
The goal must be to NOT tie a JMS 2.0 implementation to the EE 7 platform.
A JMS 2.0 vendor should be able to integrate with older EE platform
implementation.
By having the JmsActivationSpec it gives the EE 7 vendors a chance to
use internal overrides for the required activation properties. But it
also gives JCA 1.5+ environments a chance for having users provide the
necessary values in their configuration.
One thing we should advocate in this context is the
ResourceAdapterAssociation such that only the really necessary values
are passed in JmsActivationSpec - following the spec; e.g. I don't see
setDestination and setConnectionFactory as necessary.
For clustered environments it really boils down to BootstrapContext,
which I think is a too big an area to touch for this update. A solution
could be to provide a hint
public interface JmsActivationSpec extends ActivationSpec
{
public boolean isClustered();
public void setClustered(boolean v);
}
Best regards,
Jesper
On 12/06/2012 10:18 AM, Sivakumar Thyagarajan wrote:
> Hi Jesper and Wilson
>
> On Thursday 06 December 2012 01:17 PM, Wilson Tian wrote:
>> I like Jasper's proposal of using a special JmsActivationSpec, and which seems should be defined in JMS SPEC.
>
> This looks like a very good proposal. Thanks for sharing this.
> I am working offline with the JMS and the EJB spec leads, to see
> how we can take this proposal forward. Please see some
> comments inline.
>
>> 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.
>
> The ability to know if a RA is operating in a clustered environment and
> know the instance name and activation name may be useful for other
> RARs. However, I have not heard of this requirement with specific
> usecases that needs these information outside the JMS context.
> So, this looks like a good choice.
>
>> 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.
>
> Yes.
>
>> 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.
>
> Yes, Message Endpoints may be non-MDBs (for instance non-MDB
> endpoints supported by a standalone connector container
> implementation that supports Message Inflow through an approach
> different from MDBs - Section 3.5 of the Connectors 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.
>
> Agreed.
>
> Thanks
> --Siva.
>
>> 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:
> ...
>>>> 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.
>
> Arguably, this makes the contract between the JMS RA and the MDB container
> more stronger and clearer. So, this is good. Since this proposal also
> extends the ActivationSpec, this is a backward compatible change.
>
> Thanks
> --Siva.
>
>>>> 2.(b) allowing Topic subscriptions to be shared or not shared across a
>>>> cluster.
>>>>
>>>
>>> As above, with the additional information needed.
>>>
>>> Best regards,
>>> Jesper
>>>
>