Details
-
Type:
Bug
-
Status:
New
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 3.1.1
-
Fix Version/s: 3.1.1
-
Component/s: None
-
Security Level: Public
-
- Environment:
- -
Activity
| Field | Original Value | New Value |
|---|---|---|
| Summary | The JMS BC does not seem to support static queues | Flexibility for AMQ's JNDI implementation |
| Fix Version/s | 3.1.1 [ 10030 ] | |
| Priority | Minor [ 4 ] | |
| Description |
At least, this is what appears from some tests with ActiveMQ 5.5.0.
The JMS BC works fine with dynamic queues. But static queues seems to be impossible to use. It only works when the client sets up the right JNDI properties, that is to say... {quote}queue.JndiQueueName = queue.physical.name{quote} See http://activemq.apache.org/jndi-support.html In fact, it seems that it is the JMS client that creates the JNDI and not AMQ itself. It can also be checked on this [JUnit test in AMQ|https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/AMQ2084Test.java]. The best solution would be to allow a SU to provide a JNDI context. The BC creates the initial context from this file and overrides the properties. Obviously, this is a temporary workaround. A long term solution should avoid duplicating the JNDI values. |
Limitations appear when using the JMS BC with ActiveMQ 5.5.0.
The JMS BC works fine with dynamic queues. But static queues seems to be impossible to use. It only works when the client, i.e. the JMS BC code, sets the right JNDI properties, that is to say... {quote}queue.JndiQueueName = queue.physical.name{quote} See http://activemq.apache.org/jndi-support.html In fact, it seems that it is the JMS client that creates the JNDI and not AMQ itself. It can also be checked on this [JUnit test in AMQ|https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/AMQ2084Test.java]. The best solution would be to allow a SU to provide a JNDI context. The BC creates the initial context from this file and overrides the properties. Obviously, this is a temporary workaround. A long term solution should avoid duplicating the JNDI values. A workaround, for the moment, is to either use dynamic queues or to configure AMQ and Petals to use an external JNDI server. |
| Description |
Limitations appear when using the JMS BC with ActiveMQ 5.5.0.
The JMS BC works fine with dynamic queues. But static queues seems to be impossible to use. It only works when the client, i.e. the JMS BC code, sets the right JNDI properties, that is to say... {quote}queue.JndiQueueName = queue.physical.name{quote} See http://activemq.apache.org/jndi-support.html In fact, it seems that it is the JMS client that creates the JNDI and not AMQ itself. It can also be checked on this [JUnit test in AMQ|https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/AMQ2084Test.java]. The best solution would be to allow a SU to provide a JNDI context. The BC creates the initial context from this file and overrides the properties. Obviously, this is a temporary workaround. A long term solution should avoid duplicating the JNDI values. A workaround, for the moment, is to either use dynamic queues or to configure AMQ and Petals to use an external JNDI server. |
Limitations appear when using the JMS BC with ActiveMQ 5.5.0.
The JMS BC works fine with dynamic queues. But static queues seem to be impossible to use. It only works when the client, i.e. the JMS BC code, sets the right JNDI properties, that is to say... {quote}queue.JndiQueueName = queue.physical.name{quote} See http://activemq.apache.org/jndi-support.html In fact, it seems that it is the JMS client that creates the JNDI and not AMQ itself. It can also be checked on this [JUnit test in AMQ|https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/bugs/AMQ2084Test.java]. The best solution would be to allow a SU to provide a JNDI context. The BC creates the initial context from this file and overrides the properties. Obviously, this is a temporary workaround. A long term solution should avoid duplicating the JNDI values. A workaround, for the moment, is to either use dynamic queues or to configure AMQ and Petals to use an external JNDI server. |