Hi, I'm knee deep in a migration to JBoss 7.1.x (from 4.04) and have question about the naming conventions of JMS destinations in local java: namespace versus the java:jboss/exported context.
In the default standalone-full.xml the example destinations are defined as:
<jms-destinations> <jms-queue name="testQueue"> <entry name="queue/test"/> <entry name="java:jboss/exported/jms/queue/test"/> </jms-queue> <jms-topic name="testTopic"> <entry name="topic/test"/> <entry name="java:jboss/exported/jms/topic/test"/> </jms-topic> </jms-destinations>
I'm curious about why the the root java: context entry does is missing the jms portion, or conversely why the exported context has it. Unless this is for backwards compatibility or some such, it seems like naming it two different ways is confusing.
Code executing inside JBoss creates an new InitialContext gets a Context which is rooted at "java:". Code that looks up the Context using remoting gets a Context rooted at java:jboss/exported. It seems if there is some code which is given a Context, it should (as much as possible) be agnostic about whether is running in or out of the JBoss instance. Adding the extra "jms" namespace to the destination name requires that the same object be looked up using difference names. I realize I can name my destination however I like, but I'd like to understand the reason for the convention.
Also, I noticed that in the JNDI view (either from the CLI or web console), the exported portion of the JNDI tree just resolves to the implementation object. It seems like it should be possible to expand that to see a view of what is exported. Anyone know if there is already an issue for this? Thanks -Dan
I would not read too much in the examples provided in AS7. In latest AS7 release, we have removed the destination examples from the standalone-full.xml file.
You would have to use your own JNDI naming conventions when you add the destinations. FWIW, I agree with you that it's better to have the same tree hierarchy between local and exported names.