You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Jason Royals (JIRA)" <ji...@apache.org> on 2008/09/13 02:57:46 UTC
[jira] Commented: (SYNAPSE-448) NullPointerException in JMSSender
when JMS config details defined in axis2.xml
[ 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org