My understanding is that you are trying to connect to MQSeries (QueueManager and Channel are MQ concepts and are not part of the JMS API AFAIK) so I think that you'll have to use MQ specific client API. I'm really not a MQ expert but it seems that the code below (see Implementing vendor-independent JMS solutions) is close to what you are looking for:
MQQueueConnectionFactory qconFactory = new MQQueueConnectionFactory();
qconFactory.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP); //Used when the MQSeries server is on a different host from the client
qconFactory.setQueueManager(queueManager);
qconFactory.setHostName(hostName);
qconFactory.setPort(port);
qconFactory.setChannel(channel);
connection = qconFactory.createQueueConnection();
session1 = connection.createQueueSession(true, Session.CLIENT_ACKNOWLEDGE);.....
As I said, I'm not a MQ specialist but the MQQueueConnectionFactory
seems to be aware of most of the things you are talking about.
Side Note:
When using JNDI, you need to set up JNDI environment properties like the initial context factory and the provider url. Basically, these properties are used to declare what class to use to create the initial context and where to find the JNDI server. Obviously, the values of these properties are dependent on the JNDI service you're connecting to.
You can specify environment properties by using the non empty InitialContext
constructor and passing the environment
parameter to it. For example to connect to BEA WebLogic JNDI service:
Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
p.put(Context.PROVIDER_URL,"t3://myhost:7001");
ctx = new InitialContext(p);
Or you can provide a jndi.properties
file and use the non-arg InitialContext
constructor. For example, to connect to IBM WebSphere JNDI service, you would put a jndi.properties
file with the following content on the classpath:
java.naming.provider.url=iiop://myhost:9001
java.naming.factory.initial=com.ibm.websphere.naming.WsnInitialContextFactory
This second approach is of course more portable as you don't hard code the values of the parameters in the Java code (this might not be an issue though).
Now, in your case, I can't tell if you need this (and even less what values to use) as you didn't provide any detail on your context (like the application server or the JMS provider or the Messaging solution you are trying to connect to).