qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Updated: (QPID-1623) Setting JMSReplyTo field to NULL causes IllegalArgumentException to be thrown
Date Wed, 11 Feb 2009 15:56:59 GMT

     [ https://issues.apache.org/jira/browse/QPID-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aidan Skinner updated QPID-1623:
--------------------------------

    Status: Ready To Review  (was: In Progress)

> Setting JMSReplyTo field to NULL causes IllegalArgumentException to be thrown
> -----------------------------------------------------------------------------
>
>                 Key: QPID-1623
>                 URL: https://issues.apache.org/jira/browse/QPID-1623
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Client
>    Affects Versions: M1, M2, M2.1, M3, M4
>            Reporter: Marnie McCormack
>            Assignee: Aidan Skinner
>             Fix For: M5
>
>
> Qpid versions 2.2.2.0 
> Platform: Windows 
> JDK: 16.0_11 
> I came across this problem while trying to write an example application for one of our
MAF clients that would take part in a JMS request-response message flow. 
> During testing of this I started hitting this IllegalArgumentException from Qpid exception:

> java.lang.IllegalArgumentException: Null destination not allowed 
>   at org.apache.qpid.client.message.AbstractJMSMessage.setJMSReplyTo(AbstractJMSMessage.java:200)

>   at org.mule.providers.jms.JmsReplyToHandler.processReplyTo(JmsReplyToHandler.java:79)

>   at org.mule.impl.model.DefaultMuleProxy.onCall(DefaultMuleProxy.java:297) 
>   at org.mule.impl.model.seda.SedaComponent.doSend(SedaComponent.java:406) 
>   at org.mule.impl.model.AbstractComponent.sendEvent(AbstractComponent.java:407) 
>   at org.mule.impl.MuleSession.sendEvent(MuleSession.java:349) 
>   at org.mule.routing.inbound.InboundRouterCollection.send(InboundRouterCollection.java:197)

>   at org.mule.routing.inbound.InboundRouterCollection.route(InboundRouterCollection.java:163)

>   at org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:585)

>   at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:322)

>   at org.mule.providers.AbstractReceiverWorker$1.doInTransaction(AbstractReceiverWorker.java:107)

>   at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:98) 
>   at org.mule.providers.AbstractReceiverWorker.doRun(AbstractReceiverWorker.java:124)

>   at org.mule.providers.AbstractReceiverWorker.run(AbstractReceiverWorker.java:60) 
>   at org.mule.impl.work.WorkerContext.run(WorkerContext.java:310) 
>   at org.mule.impl.work.SyncWorkExecutor.doExecute(SyncWorkExecutor.java:39) 
>   at org.mule.impl.work.MuleWorkManager.executeWork(MuleWorkManager.java:277) 
>   at org.mule.impl.work.MuleWorkManager.doWork(MuleWorkManager.java:169) 
>   at org.mule.providers.jms.MultiConsumerJmsMessageReceiver$SubReceiver.onMessage(MultiConsumerJmsMessageReceiver.java:281)

>   at org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:719)

>   at org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:656)

>   at org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3043)

>   at org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:2966) 
> After doing some digging through the Mule code I was able to track it down to the following
piece of code in Mule's JmsReplyToHandler where it tries to set the JMSReplyTo field to be
null. 
>   final boolean topic = connector.getTopicResolver().isTopic(replyToDestination); 
>   session = connector.getSession(false, topic); 
>   Message replyToMessage = JmsMessageUtils.toMessage(payload, session); 
>   replyToMessage.setJMSReplyTo(null); 
>   if (logger.isDebugEnabled()) 
>   { 
>      logger.debug("Sending jms reply to: " + replyToDestination + "(" 
>                   + replyToDestination.getClass().getName() + ")"); 
>   } 
>   replyToProducer = connector.getJmsSupport().createProducer(session, replyToDestination,
topic); 
> The corresponding code in qpid (taken from the AbstractJMSMessage class) shows that qpid
throws the IllegalArgumentException whenever it receives a null value: 
>     public void setJMSReplyTo(Destination destination) throws JMSException 
>     { 
>         if (destination == null) 
>         { 
>             throw new IllegalArgumentException("Null destination not allowed"); 
>         } 
>         if (!(destination instanceof AMQDestination)) 
>         { 
>             throw new IllegalArgumentException( 
>                     "ReplyTo destination may only be an AMQDestination - passed argument
was type " + destination.getClass()); 
>         } 
>         final AMQDestination amqd = (AMQDestination) destination; 
>         final AMQShortString encodedDestination = amqd.getEncodedName(); 
>         _destinationCache.put(encodedDestination, destination); 
>         getContentHeaderProperties().setReplyTo(encodedDestination); 
>     } 
> The JMS Spec is a bit vague around whether or not you can actually set this JMSReplyTo
value to null or not but after talking with Martin about this he was able to check both the
Qpid and MQ code to see how they compared. While the Qpid code disallows setting a null value
on the JMSReplyTo field the MQ code is more forgiving and allows Null values to be set. I've
included the JMSReplyTo section from the JMS Spec below. 
> ----- 
> 3.4.6 JMSReplyTo 
> The JMSReplyTo header field contains a Destination supplied by a client when a message
is sent. It is the destination where a reply to the message should be sent. 
> Messages sent with a null JMSReplyTo value may be a notification of some event or they
may just be some data the sender thinks is of interest. Messages sent with a JMSReplyTo value
are typically expecting a response. A response may be optional; it is up to the client to
decide. 
> ----- 
> Ideally I would like for this null check in the qpid code to be removed if possible as
at the moment it's stopping me from using qpid for this example for one of our clients. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message