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
(This is a duplicate of an email I sent to users_at_glassfish.dev.java.net)
[Message sent by forum member 'nigeldeakin' (nigeldeakin)]
http://forums.java.net/jive/thread.jspa?messageID=352631