Petals BC JMS

Flexibility for AMQ's JNDI implementation

Details

  • Type: Bug Bug
  • Status: New New
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 3.1.1
  • Fix Version/s: 3.1.1
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    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...

    queue.JndiQueueName = queue.physical.name

    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. 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.

    Show
    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...
    queue.JndiQueueName = queue.physical.name
    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. 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.
  • Environment:
    -

Activity

Hide
Christophe DENEUX added a comment - Wed, 4 Jul 2012 - 11:43:05 +0200

In which mode have you the problem: consume, provide or both ?

Show
Christophe DENEUX added a comment - Wed, 4 Jul 2012 - 11:43:05 +0200 In which mode have you the problem: consume, provide or both ?
Hide
Vincent Zurczak added a comment - Wed, 4 Jul 2012 - 11:45:38 +0200

I have the problem when I try to consume a JMS message (and so when I try to consume a Petals service).
But I guess I would have the same problem in provide mode. This is an issue with the JNDI.

Show
Vincent Zurczak added a comment - Wed, 4 Jul 2012 - 11:45:38 +0200 I have the problem when I try to consume a JMS message (and so when I try to consume a Petals service). But I guess I would have the same problem in provide mode. This is an issue with the JNDI.
Hide
Vincent Zurczak added a comment - Wed, 4 Jul 2012 - 12:10:03 +0200

See http://activemq.2283324.n4.nabble.com/JNDI-usage-td2352964.html
JNDI interactions with AMQ do not really respect the JMS paradigm. Either we add properties in the initial context, or we have to use an external JNDI server with AMQ.

Show
Vincent Zurczak added a comment - Wed, 4 Jul 2012 - 12:10:03 +0200 See http://activemq.2283324.n4.nabble.com/JNDI-usage-td2352964.html JNDI interactions with AMQ do not really respect the JMS paradigm. Either we add properties in the initial context, or we have to use an external JNDI server with AMQ.

People

Dates

  • Created:
    Wed, 4 Jul 2012 - 11:18:34 +0200
    Updated:
    Wed, 4 Jul 2012 - 15:45:53 +0200