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
>>