How do I distinguish a QueueSession from a TopicSession, when I have obtained the session reference via a call to TopicSession.createTopicSession() or QueueSession.createQueueSession() at some prior point in the code? Can anyone describe WebLogic's specific implementation of the Destination/Topic/Queue and Session/TopicSession/QueueSession classes, that accounts for 'instanceof' returning 'true' for BOTH QueueSession and TopicSession, and for both Queue and Topic?
Why I'm asking:
Some legacy code I'm working on has had a new Topic configured, and a new message is being sent
on that topic from the server, but it is not received by the client applet. I've traced the problem to a low-level JMS-related function in the application's server-side code, which instantiates a QueueSender instead of a TopicPublisher where it should not, and then sends the message via that incorrect means.
This mistake occurs because a JMSSession object reference is passed into the function as a parameter, and the function immediately checks if it's a reference to a QueueSession, in particular. That check unexpectedly succeeds even when the passed-in object reference is to a TopicSession, thus causing the function to *always* instantiate the QueueSender.
Again, to be clear -- if BOTH the following instanceof tests are present, BOTH return true:
if (theSessionParameter instanceof QueueSession)
if (theSessionParameter instanceof TopicSession)
Presumably, this occurs because the passed-in object is actually of type weblogic.jms.client.JMSSession, which is apparently generic enough to pass both tests.
Some pertinent points:
1) The topic/destination reference that is passed in as a parameter was first obtained via a
TopicSession.createTopicSession() call, which returns a weblogic.jms.client.JMSSession reference,
and then that JMSSession reference is cast specifically to a TopicSession reference.
2) The topic/destination to which the message is sent is (to all appearances) correctly configured
as a JMSTopic and *not* as a JMSQueue in config.xml and elsewhere, so that should not
introduce any conflict or confusion when it is sent. (BTW, after a JNDI lookup() call for the
topic/destination name, I've noticed that existing 'instanceof' checks in the code that check for a
Queue versus a Topic similarly BOTH succeed for the returned object, which is of type
weblogic.jms.common.DestinationImpl. So some similar mechanism is operating there and
I'll no doubt have to make some related changes in that pre-existing code, as well.