Thanks for the reply.
[i]"NOTE: If you have purchased support for glassfish, you can escalate to
get one/both of the possible changes (see below) in the current product
back ported either to the broker or the MQ resource adapter."[/i]
We have purchased support for GlassFish, but other than the initial contact from the support group I have not had anyone contact me since we opened the issue. (That's been 3 days now) Your help has been very valuable to me. Thanks for responding to both threads.
So as I listed in bug 6580:
[i]
"I'm sorry if I am missing something here pertaining to the configuration of the
ConnectionFactory (Managed Object) in the GlassFish container but none of these
options seems to work as needed. Let me try and address them.
EclipseLink is designed to allow us to utilize JMS for Cache Coordination. It
does this in a standard way by allowing us to specify the properties that are
used to acquire an InitiaContext. We also specify the JNDI path to the
TopicConnectionFactory and the Topic itself.
Example:
public void customize(Session session) throws Exception {
RemoteCommandManager rcm = new RemoteCommandManager((CommandProcessor) session);
java.util.Properties props = new java.util.Properties();
props.put(Context.PROVIDER_URL, getProviderURL());
props.put(Context.INITIAL_CONTEXT_FACTORY, getInitialContextFactory());
JMSTopicTransportManager tm = new JMSTopicTransportManager(rcm);
tm.setLocalContextProperties(props);
tm.setRemoteContextProperties(props);
tm.setTopicName(getJmsTopicName());
tm.setTopicConnectionFactoryName(getJmsConnectionFactoryName());
tm.setUserName(getUserName());
tm.setPassword(getPassword());
....
EclipseLink allows us to specify the local and remote contexts. Local is for
creating a subscriber and remote is for creating a publisher. (Usually both
Local and Remote would be the same.) This is due to EclipseLink publishing
entity changed to the topic. The subscriber receives those changes to apply to
entities within the cache or to invalidate those entities. Both Local and Remote
are treated separately, so each will have a reference to a separate connection.
Now, if I were to set the ClientID on the ConnectionFactory that is managed in
JNDI by GlassFish, the ClientID is set on all connections created. The problem
with this is that it only works correctly for the first connection. The second
connection created will throw an exception because the ClientID is already in
use. (I know for a fact because I tried it)
So it makes sense that the ClientID must be generated and unique. Seems to me I
could set it easily after creating the connection. Something like:
TopicConnection topicConnection=connectionFactory.createTopicConnection();
topicConnection.setClientID(getClientID());
...
But this too fails due to a little piece of code in GlassFish that prevents the
ClientID from being set outside of the Application Container:
Referring to com.sun.messaging.jms.ra.ConnectionAdapter :
public void setClientID(String clientId) throws JMSException {
_loggerJC.entering(_className, "setClientID()", clientId);
//System.out.println("MQRA:CA:setClientID-to-"+clientId);
if (!inACC) {
throw new com.sun.messaging.jms.JMSException(
"MQRA:CA:Unsupported-setClientID()");
}
checkClosed();
xac.setClientID(clientId);
}
The above code prevents me from setting the ClientID from within my application
code. (Again, I've tried..) When I call setClientID(...) I get the JMSException
listed above.
[/i]
So right now I really have no choices remaining other than going directly to the JMS Server and by-passing the managed objects in the container.
[Message sent by forum member 'cmathrusse' (cmathrusse)]
http://forums.java.net/jive/thread.jspa?messageID=352116