You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by edan <Ed...@PremierInc.com> on 2010/03/17 19:45:36 UTC
ActiveMQ's JNDI does not resolve XAConnectionFactory
I've tried googling for a reasonable amount of Internet time (more than 5-10
minutes), and I've found a few old posts that seem similar but no clear
answer. In short, we are using ActiveMQ 5.3.0 to bridge to a third party
using webMethods. Everything has been great using ActiveMQ's builtin JNDI
when we were look up "ConnectionFactory" and using dynamicQueue/QueueName
syntax for destination names.
But for a particular work flow, we need to use use XA transactions to
provide roll back. I tried several enumerations of getting webMethods to
lookup "XAConnectionFactory" in ActiveMQ's JNDI. I tried specifying
ActiveMQXAConnectionFactory to lookup via JNDI, I tried adding mappings for
ActiveMQXAConnectionFactory in "Other Properties" for the JNDI Provider
(which I believe is webMethods speak for jndi.properties).
We have had some success defining an XAConnectionFactory in a Sun Directory
Server and then defining queues individually in LDAP (there doesn't seem to
be a way to do a cn=dynamicQueue... bleah), but life would be so much easier
if ActiveMQ's handy little JNDI resolved XAConnectionFactory!
I tried a quick hack of
org.apachemq.jndi.ActiveMQInitialContextFactory.java:
private static final String[] DEFAULT_CONNECTION_FACTORY_NAMES =
{"ConnectionFactory", "QueueConnectionFactory", "TopicConnectionFactory",
"XAConnectionFactory", "ActiveMQXAConnectionFactory"};
And it compiled, but didn't change anything as far as I can tell. That made
me think I would have to actual work to fix it.
Any ideas out there? Is there some reason the builtin JNDI can't resolve
XAConnectionFactory? I'm bit green in this area anyway, so perhaps there is
some trickiness I don't understand. Should I just dig into the initial
factory java code a bit more?
I appreciate any help; it's been enjoyable getting to know the software.
- edan
--
View this message in context: http://old.nabble.com/ActiveMQ%27s-JNDI-does-not-resolve-XAConnectionFactory-tp27936255p27936255.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: ActiveMQ's JNDI does not resolve XAConnectionFactory
Posted by Gary Tully <ga...@gmail.com>.
Yea, it is a simple in memory hash map configured from the environment.
I was thinking of a new property, xa=true|false that could trigger the
creation of an XA variant of the connection factory.
I think doing XA by default may upset clients what check for an XA
connection factory, transaction wrappers and the like.
Can you raise a jira issue for this enhancement and attach your changes to
that so that they are not lost.
On 18 March 2010 18:39, edan <Ed...@premierinc.com> wrote:
>
>
> Gary Tully wrote:
> >
> > you need to change
> > the
> >
> org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(Hashtable)
> > method to optionally create an ActiveMQXAConnectionFactory
> > I think it would be a sensible default but having a property that can
> > ensure
> > that a particular factory is xa would be a nice addition.
> > have a look
> > at
> >
> org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(String,
> > Hashtable) to see the naming convention for how additional properties are
> > specified.
> >
>
> Thanks for the quick response, Gary! I think a stumbling block for me was
> that I assumed the openwire connector had some magic JNDI code inside--I
> didn't realize the JNDI connectionfactory lookup was really all on the
> client side :)
>
> I didn't quite understand how to modify
> ActiveMQInitialContextFactory.createConnectionFactory() to optionally
> create
> an ActiveMQXAConnectionFactory, though, since it returns an
> ActiveMQConnectionFactory. Are you suggesting it could always return
> ActiveMQXAConnectionFactory and let people cast it to a plain
> ConnectionFactory when they don't want XA?
>
> My quick patch which seems to be working was to modify the
> getInitialContext(environment) method to create a
> ActiveMQXAConnectionFactory when the "name" from the environment equals
> "XAConnectionFactory" and I copied the two createConnectionFactory()
> methods
> and made createXAConnectionFactory methods, so it looks like:
> http://old.nabble.com/file/p27949733/ActiveMQInitialContextFactory.java
> ActiveMQInitialContextFactory.java
>
> I suppose it would be less duplicated code to always return an
> ActiveMQXAConnectionFactory, but I wasn't sure about that part. I'll think
> about it some more, let me know what you think of my current hack ;)
>
> Thanks again.
> --
> View this message in context:
> http://old.nabble.com/ActiveMQ%27s-JNDI-does-not-resolve-XAConnectionFactory-tp27936255p27949733.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: ActiveMQ's JNDI does not resolve XAConnectionFactory
Posted by edan <Ed...@PremierInc.com>.
Gary Tully wrote:
>
> you need to change
> the
> org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(Hashtable)
> method to optionally create an ActiveMQXAConnectionFactory
> I think it would be a sensible default but having a property that can
> ensure
> that a particular factory is xa would be a nice addition.
> have a look
> at
> org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(String,
> Hashtable) to see the naming convention for how additional properties are
> specified.
>
Thanks for the quick response, Gary! I think a stumbling block for me was
that I assumed the openwire connector had some magic JNDI code inside--I
didn't realize the JNDI connectionfactory lookup was really all on the
client side :)
I didn't quite understand how to modify
ActiveMQInitialContextFactory.createConnectionFactory() to optionally create
an ActiveMQXAConnectionFactory, though, since it returns an
ActiveMQConnectionFactory. Are you suggesting it could always return
ActiveMQXAConnectionFactory and let people cast it to a plain
ConnectionFactory when they don't want XA?
My quick patch which seems to be working was to modify the
getInitialContext(environment) method to create a
ActiveMQXAConnectionFactory when the "name" from the environment equals
"XAConnectionFactory" and I copied the two createConnectionFactory() methods
and made createXAConnectionFactory methods, so it looks like:
http://old.nabble.com/file/p27949733/ActiveMQInitialContextFactory.java
ActiveMQInitialContextFactory.java
I suppose it would be less duplicated code to always return an
ActiveMQXAConnectionFactory, but I wasn't sure about that part. I'll think
about it some more, let me know what you think of my current hack ;)
Thanks again.
--
View this message in context: http://old.nabble.com/ActiveMQ%27s-JNDI-does-not-resolve-XAConnectionFactory-tp27936255p27949733.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: ActiveMQ's JNDI does not resolve XAConnectionFactory
Posted by Gary Tully <ga...@gmail.com>.
you need to change
the org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(Hashtable)
method to optionally create an ActiveMQXAConnectionFactory
I think it would be a sensible default but having a property that can ensure
that a particular factory is xa would be a nice addition.
have a look
at org.apache.activemq.jndi.ActiveMQInitialContextFactory.createConnectionFactory(String,
Hashtable) to see the naming convention for how additional properties are
specified.
Would make a nice patch!
On 17 March 2010 18:45, edan <Ed...@premierinc.com> wrote:
>
> I've tried googling for a reasonable amount of Internet time (more than
> 5-10
> minutes), and I've found a few old posts that seem similar but no clear
> answer. In short, we are using ActiveMQ 5.3.0 to bridge to a third party
> using webMethods. Everything has been great using ActiveMQ's builtin JNDI
> when we were look up "ConnectionFactory" and using dynamicQueue/QueueName
> syntax for destination names.
>
> But for a particular work flow, we need to use use XA transactions to
> provide roll back. I tried several enumerations of getting webMethods to
> lookup "XAConnectionFactory" in ActiveMQ's JNDI. I tried specifying
> ActiveMQXAConnectionFactory to lookup via JNDI, I tried adding mappings for
> ActiveMQXAConnectionFactory in "Other Properties" for the JNDI Provider
> (which I believe is webMethods speak for jndi.properties).
>
> We have had some success defining an XAConnectionFactory in a Sun Directory
> Server and then defining queues individually in LDAP (there doesn't seem to
> be a way to do a cn=dynamicQueue... bleah), but life would be so much
> easier
> if ActiveMQ's handy little JNDI resolved XAConnectionFactory!
>
> I tried a quick hack of
> org.apachemq.jndi.ActiveMQInitialContextFactory.java:
>
> private static final String[] DEFAULT_CONNECTION_FACTORY_NAMES =
> {"ConnectionFactory", "QueueConnectionFactory", "TopicConnectionFactory",
> "XAConnectionFactory", "ActiveMQXAConnectionFactory"};
>
> And it compiled, but didn't change anything as far as I can tell. That
> made
> me think I would have to actual work to fix it.
>
> Any ideas out there? Is there some reason the builtin JNDI can't resolve
> XAConnectionFactory? I'm bit green in this area anyway, so perhaps there
> is
> some trickiness I don't understand. Should I just dig into the initial
> factory java code a bit more?
>
> I appreciate any help; it's been enjoyable getting to know the software.
>
> - edan
>
>
>
> --
> View this message in context:
> http://old.nabble.com/ActiveMQ%27s-JNDI-does-not-resolve-XAConnectionFactory-tp27936255p27936255.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com