Noah,
>> As you have discovered, one difference between a
>> com.sun.messaging.jms.ra.ConnectionAdapter and a
>> simple MQ connection is that you can't set ClientID
>> on a ConnectionAdapter . If you try you get the
>> message "MQRA:CA:Unsupported-setClientID()".
>>
>> Instead you need to set ClientID on its connection
>> [i]factory [/i](i.e. on the
>> com.sun.messaging.jms.ra.ManagedConnectionFactory).
>
> OK I have a few observations with this:
>
> * Setting the clientID in this fashion is non-portable as I must specifically do so with the
> com.sun.messaging.jms.ra.ManagedConnectionFactory class because the javax.resource.spi.ManagedConnectionFactory
> interface does not have a setClient() method. Outside of GF JMSRA setting the clientId can be done against
> the TopicConnection interface and is therefor portable.
In fact setting the clientID on the connection factory is the recommended way, and the way you configure a connection
factory is deliberately expected to be provider-specific:.
In the JMS 1.1 spec, section 4.3.2 "Client Identifier" on p55 states "The preferred way to assign a client’s client
identifier is for it to be configured in a client-specific ConnectionFactory and transparently assigned to theconnection
it creates. "
> * All connections from the same factory will have the same clientID, where as before I could
> set this on a per connection basis vs. per factory basis. Is there a particular reason for the design choice
> of shifting setting clientId to the factory?
It's required by the Java EE 5.0 specification. Section EE.6.6 (Java™ Message Service (JMS) 1.1 Requirements) on page 32
gives a list of methods which "may only be used by application components executing in the application client
container". The list includes "javax.jms.Connection method setClientID". It goes on to say "a Java EE container may
throw a JMSException... if the application component violates these restrictions."
(Sorry to keep quoting specs at you, but ultimately they explain why the product behaves as it does).
>
>> You can set these properties using the Glassfish
>> admin console or using the Glassfish asadmin
>> create-jms-resource command, which is its
>> command-line equivalent.
>
> Currently the code I am porting is patterned such that when a class wishes to act as a durable subscriber it extends
> a 'TopicMessageListener' and passes in a destination and subscriber name which previously was used to set the
> unique clientID on the connection. This class would also have access to the ManagedConnectionFactory
> (after I make a few changes) . Based on your information it sounds like having it set the clientID on the
> ManagedConnectionFactory in the same fashion it did on the connection is the way I need to go.
Why are you creating a durable subscription programmatically? The recommended way to receive messages from a durable
subscriber in a Java EE environment would be to define a MDB - in which case you would define clientID and subscription
name in the MDB config (the "activation spec").
Nigel