• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 506
  • Last Modified:

Distinguishing QueueSession from TopicSession After WebLogic's TopicSession.createTopicSession() Call

My Question:  

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.


0
RosieDark
Asked:
RosieDark
1 Solution
 
RosieDarkRetired Senior Software EngineerAuthor Commented:
I've found a partial answer to my own question.  I'm posting it for the benefit of the rest of y'all:

================================================================
With Regard to Distinguishing a Queue from a Topic, when one has a weblogic.jms.common.DestinationImpl object:

Yes, my speculation was correct, per BEA, that the weblogic.jms.common.DestinationImpl class implements both javax.jms.Queue and javax.jms.Topic.  And yes, this creates a problem distinguishing them, so BEA provides an undocumented work-around API call to replace the
use of the instanceof operator.  (BEA says that normally only the javadoc'd methods are intended
for public use, but in this case they make an exception.)

Replace your instanceof operation with:
       ((weblogic.jms.common.DestinationImpl)dest).isQueue()


But be forewarned ... "The next release will deprecate the work-around in favor of an extension interface, which will be very similar - something like:

     ((weblogic.jms.extensions.WLDestination)dest).isQueue()

================================================================
With Regard to Distinguishing a QueueSession from a TopicSession, when one has a weblogic.jms.client.JMSSession object:

Still searching for the answer; probably something equivalent to what's been provided above for Destinations.
0
 
moduloCommented:
PAQed with points refunded (250)

modulo
Community Support Moderator
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now