[
https://issues.apache.org/jira/browse/SYNAPSE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630723#action_12630723
]
Jason Royals commented on SYNAPSE-448:
--------------------------------------
Just an addition to this, just changing the endpoint in synapse.xml from using
"transport.jms.ConnectionFactory" to the less-reusable equivalent (eg,
jms:/queuename?transport.jms.ConnectionFactoryJNDIName=QueueConnectionFactory&java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&transport.jms.ConnectionFactoryType=queue)
didn't work either, at least not intially.
I found that JMSSender is doing something I didn't expect when it looks for a
JMS Connection to use. JMSSender, if it cannot find a cached connection
factory by name, will iterate over the axis2.xml configured factories and look
for equivalence between the fully-qualified jms:/ URI and a pre-configured
factory for each JMS message (JMSSender:117). If it finds one (JMSSender:92),
it uses the pre-configured connection factory instead of creating a new one.
That's fine, but it's not what I expected to happen. Synapse should probably
log something here to advise that it's found some equivalence in the
pre-configured factory and will use it instead of creating the new one.
Unfortunately, when Synapse uses the cached factory, it then follows the same
code path as described in the original report, and will break for the same
reasons.
Workaround for this is to simply remove the definition from axis2.xml, and my
test goes peachy green. That's not what I want though because my endpoint now
knows too much about the JMS implementation, and we cannot switch JMS
implementations without changing the endpoint itself.
> NullPointerException in JMSSender when JMS config details defined in axis2.xml
> ------------------------------------------------------------------------------
>
> Key: SYNAPSE-448
> URL: https://issues.apache.org/jira/browse/SYNAPSE-448
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Environment: Any
> Reporter: Jason Royals
>
> I am proxying a JMS service over HTTP. The JMS service responds with some
> XML, so the JMSSender expects a reply. To make my endpoint more reusable,
> I'm putting the JMS connection details in axis2.xml (as detailed in
> SYNAPSE-183). What's actually happening though is that the HTTP client is
> just timing out. I ran the debugger over Synapse to see what was going on,
> and it looks like a defect with the implementation of that feature.
> To listen for a JMS reply from the endpoint, Synapse starts a connection
> (JMSSender:267) after sending the message. However, this connection is only
> ever initialised if the JMS connection is _not_ defined in axis2.xml, due to
> the if/else that checks for an already established connectionFactory at the
> key "transport.jms.ConnectionFactory" (JMSSender:119). This means the
> connection is always null when using this feature, and a NPE will be thrown
> at line 267.
> I'll supply a test if required.
> Cheers,
> Jason
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
