How does Queue or Topic Proxy differ from DestinationImpl?

Connectors & Integrations
, ,
1

java.lang.ClassCastException: com.solacesystems.jms.ra.outbound.QueueProxy cannot be cast to weblogic.jms.common.DestinationImplStack Trace for RuntimeException was:java.lang.ClassCastException: com.solacesystems.jms.ra.outbound.QueueProxy cannot be cast to weblogic.jms.common.DestinationImpl

occurring

The configurations were all correctly done and connection, session, messageProducer were all getting established (inferred through debug statements) but still for some reason the message could not be sent.

After a few days of fruitless search I came across a code snippet and I modified a single line in my code to this:


Topic topic = session.createTopic("MyTopic"); //This is the physical name of the topic at Solace. `           `

*and voila, * IT WORKED. I dont know why it didnt work with JNDI mapping. Maybe weblogic handles topic class casting differently but the same solution does not work for the consumer code despite many tries.

Can someone explain why this is the case?

Thanks.

2

Hi @SHADOW . I just noticed this thread never got a reply on. Have you made any progress on this issue?

The one thing from your snippets above that strikes me as odd (not necessarily incorrect, I’m just not super familiar): you are using weblogic.jndi.WLInitialContextFactory as your context factory. So, using WebLogic as an external JNDI lookup provider, vs. using Solace com.solacesystems.jndi.SolJNDIInitialContextFactory . Correct? How have you configured the external JNDI? Does it have all the same (Solace-specific) properties as Solace connection factory? Like, since using WebLogic JNDI for initial context, I’m not sure exactly how it would handle a JNDI topic lookup? I mean, it could work, but I’m not sure. Too bad a JMS expert doesn’t weigh in here.

Ah, looking at this sample code here , maybe this is something to help?


// lookup the connection factory
SolConnectionFactory cf = (SolConnectionFactory)ctx.lookup(cfName);
// lookup the destination
Object destination = ctx.lookup(destinationName);
// Create a JMS Connection instance .
connection = cf.createConnection();
// Create a non-transacted, client ACK session.
Session session = connection.createSession(false, SupportedProperty.SOL_CLIENT_ACKNOWLEDGE);
// Create the producer and consumer
MessageConsumer consumer = null;
MessageProducer producer = null;
if (destination instanceof Topic) {
    Topic topic = (Topic)destination;
    consumer = session.createConsumer(topic);
    producer = session.createProducer(topic);
} else if (destination instanceof Queue) {
    Queue queue = (Queue)destination;
    consumer = session.createConsumer(queue);
    producer = session.createProducer(queue);
} else {

Maybe not. Although, your casting exception occurs during the send() method, and not here, right?


Topic topic = (Topic) initialContext.lookup(TOPIC_JNDI_NAME);

So that means that the lookup succeeds? And returns a valid JMS Topic destination. So I’m guessing that maybe the particular send() call you’re using is overloaded or not pure JMS, and is expecting a Solace topic vs. JMS topic or something? Hmmm, just checked the JavaDocs , and that looks ok too.

I’m not sure. Let us know if you have an update!

3

Hi @Aaron ,

you are using weblogic.jndi.WLInitialContextFactory as your context factory. So, using WebLogic as an external JNDI lookup provider, vs. using Solace com.solacesystems.jndi.SolJNDIInitialContextFactory . Correct? How have you configured the external JNDI? Does it have all the same (Solace-specific) properties as Solace connection factory?

Yes that is correct. Since I was trying to integrate my application, which is already deployed on weblogic and uses JMS for status messages, with Solace…I figured it would be convenient to use the same for connection configurations.

The external JNDI works perfectly for establishing the connection and session objects however the topic or queue does not seem to work with weblogic’s implementation for some reason.

Ah, looking at this sample code here , maybe this is something to help?

I see that in this code the destination is initialized with “Object” class and later checked whether it is an Instance of Queue or Topic maybe that could be the issue with Weblogic trying to type cast it differently?

Anyways I did solve the issue by bypassing the JNDI lookup and instead directly giving the actual destination name of my Topic/Queue configured at the Solace.

Haven’t looked at this issue further since our project is still at a POC stage, but will update if I find anything new regarding this.

4

Anyways I did solve the issue by bypassing the JNDI lookup and instead directly giving the actual destination name of my Topic/Queue configured at the Solace.

Cool, yeah just using the “physical” name of the destination rather than JNDI. Probably a better way to go anyhow, especially if you want to use Solace features like Topic-to-Queue mapping and dynamic hierarchical topics… can’t be publishing to a static topic, won’t take advantage.

The external JNDI works perfectly for establishing the connection and session objects however the topic or queue does not seem to work with weblogic’s implementation for some reason.

In your external JNDI, have you imported some/all the various Solace messaging-specific parameters that we expose in our connection factory? Otherwise, I’m guessing it would just be the Solace defaults for everything.