views:

686

answers:

6
+2  Q: 

JMS without JNDI?

We are running portlets in WebSphere 6.01, using Java 1.4. We want to send JMS messages to a JBoss 5 queue, running Java 5 (or maybe 6, but it's certainly newer than 1.4). Trying to connect using JNDI is not working, since we have to include the JBoss client jars in the classpath of the portlet, and they are Java 1.5. So I get an unsupported major/minor error when I try to create the InitialContext.

Can we connect straight to JBoss without using JNDI? Or is there some way to get around this issue I can't think of?

+2  A: 

Even if you were able to connect to JMS without going through JBoss's JNDI, you would still need to include the JBoss client JAR in order to use JMS. Both JNDI and JMS are APIs, and you need the server's implementation of that client API in order to talk to the server.

skaffman
A: 

I think JNDI is the only way that you can create JMS connection factories and destinations (queue or topic), and these are your means of communication.

paradisonoir
+1  A: 

Depending on the JBoss version you can directly instantiate all the JMS objects.

One particular version: see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/using-jms.html

(Section 5.5. Directly instantiating JMS Resources without using JNDI)

Serge Merzliakov
A: 

In fact using JNDI is a way to be independant of the JMS provider, because you can easly change it. But if you've got no problem with that most provider offer facilities to create a connection factory and destinations

BenZen
A: 

If it's just your JNDI classes that prereq Java 5 and not the JBoss classes then you can do this. But you would have to set all of the properties of the objects and that is provider-specific. The WebSphere MQ JMS samples show how to do this with WMQ and you would need to know the property and value names for JBoss to make the equivalent code. Here is a code snippet from the WMQ JmsProducer.java sample:

  JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
  JmsConnectionFactory cf = ff.createConnectionFactory();

  // Set the properties
  cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host);
  cf.setIntProperty(WMQConstants.WMQ_PORT, port);
  cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel);
  cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
  cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName);

  // Create JMS objects
  connection = cf.createConnection();
  session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
  if (isTopic) {
    destination = session.createTopic(destinationName);
  }
  else {
    destination = session.createQueue(destinationName);
  }
  producer = session.createProducer(destination);

On the other hand, if your JBoss classes prereq Java 1.5 then you need to run Java 1.5 or better.

T.Rob
A: 

It sounds like the problem isn't with JNDI but with the conflicting classnames between the environments.

You could try doing the classloading yourself when you try to instantiate the JBOSS client classes. That way you get a separate classloader from the one that loaded the Portlet. Just make sure you understand whether you need Parent-first or Parent-last behavior. Also on that page is debugging classloading which can show you how to set the Classpath for the classloader so you can isolate the JBOSS libraries and avoid classname collisions. It is a good resource for understanding even advanced classloading issues.

Kelly French