Tags

, ,

jndi.properties example
-----------------------
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url = tcp://localhost:61616
java.naming.security.principal=system
java.naming.security.credentials=manager
connectionFactoryNames = CF
topic.test1 = jms.test.topic

topic.for.sub1 = jms.csco, jms.msft, jms.orcl
topic.for.sub2 = jms.hd, jms.intc
topic.for.sub3 = jms.aapl, jms.goog.a
topic.for.sub4 = jms.goog.*
topic.for.sub5 = jms.goog.>


Pros:
- jndi.properties can map physical topics into a logic one for a particular sub
- most common jms broker uses jndi
- support thru a jndi server

Cons:
- yet another layer of mapping, more files involved when making changes

Overview:
Steps from "test1" to "jms.test.topic",
test1 -> topic.test1 -> Topic obj -> getTopicName() -> jms.test.topic

Details:
Basically, left hand side is the name used for lookup in jndi.
"topic." is more like a keyword/prefix, by convention would indicate a jms topic.

The LHS is referred as the logic name, ie,

    topic.[jndi_name] 

where "jndi_name" is "test1" in our case,
and "jms.test.topic" is referred as the physical name.

And "test1" should be used (not "topic.test1") to get the Topic object, hence dropping the "topic." prefix before lookup.
ie.
   Topic chatTopic = (Topic)ctx.lookup("test1");

and where chatTopic.getTopicName() should return jms physical name,
ie.
    jms.test.topic

So, the JMS topic naming hierarchy should be on RHS in jndi.properties
There is no wildcard support on the LHS.

Advertisements