synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Royals (JIRA)" <>
Subject [jira] Commented: (SYNAPSE-448) NullPointerException in JMSSender when JMS config details defined in axis2.xml
Date Sat, 13 Sep 2008 00:57:46 GMT


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&amp;java.naming.factory.initial=org.apache.activemq.jndi.ActiveMQInitialContextFactory&amp;java.naming.provider.url=tcp://localhost:61616&amp;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:
>             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:
For additional commands, e-mail:

View raw message