Nigel,
Thanks for the clarification. It might be useful to add this fact to the documentation. The documentation disconnect for me, coming to this platform fresh, is that when I look at the available documentation on the subject of JMS administered objects the OpenMQ docs approach it using their tools and the Glassfish PDF docs approach it from the point of view of asadmin (the GF Admin portal online help gives you some info on this from that context) which as you point out is limited by what the JMSRA exposes.
With this limitation of GF created JMS administered objects in mind perhaps you can shed some light onto what I am seeing related to my previous post here:
http://forums.sun.com/thread.jspa?threadID=5388659&tstart=0
Thanks to Linda's information I was able to get my legacy code to work in GF/OpenMQ with one important caveat. It only works if the administered objects I created were created with OpenMQ's administration tools. If I create them using GF the code goes back to it's behavior of complaining that the clientID can not be set with connection.setClientID(). It appears to be the resource adapter that's doing the complaining:
[i]com.sun.messaging.jms.JMSException: MQRA:CA:Unsupported-setClientID()
at com.sun.messaging.jms.ra.ConnectionAdapter.setClientID(ConnectionAdapter.java:152)[/i]
Looking at the 4.3 OMQ source for ConnectionAdapter suggests that this happens because the code is not being run in an ACC which is true but that would also imply that if I can't set it in code then it would be the GF containers responsibility to set it, correct?
If I don't use setClientID then I get the following:
javax.jms.JMSException: [C4053]: Invalid client ID - ""
Which seems to imply that the GF container isn't setting it either.
Again this is if I switch the InitialContext to using the default empty constructor which uses:
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming:com.sun.enterprise.naming:com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl:com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl:com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
I end up looking up the JMS administered objects I created using GF.
If I instead feed my InitialContext the same parameters I used when using the OpenMQ tools:
java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
java.naming.provider.url=file:///C:/imq_admin_objects
the code works without a hitch.
However, even though it works I still have a bit of a bad taste in my mouth about it and I would like to better understand what is behind the behavior I am seeing and what limitations or issues I might have using the non-GF created administered objects. For example I probably can't use resource injection with them correct?
Thanks,
-NBW
[Message sent by forum member 'emailnbw' (emailnbw)]
http://forums.java.net/jive/thread.jspa?messageID=352534