camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott England-Sullivan (JIRA)" <>
Subject [jira] [Commented] (CAMEL-6180) SJMS Component behavior suggestions to improve upon the standard JMS component
Date Tue, 16 Sep 2014 21:19:34 GMT


Scott England-Sullivan commented on CAMEL-6180:

Hi Randy,

Regarding number #5, see CAMEL-7825.  Work is now in progress via contribution by Andrew Block.

Scott ES

> SJMS Component behavior suggestions to improve upon the standard JMS component
> ------------------------------------------------------------------------------
>                 Key: CAMEL-6180
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-sjms
>            Reporter: Matt Pavlovich
>            Assignee: Scott England-Sullivan
> The SJMS component should not suffer any feature loss from the standard JMS component,
for best user experience in 3.0. 
> A random mix of suggested behavior changes/enhancements:
>  1. Supporting things like consume from multiple destinations using wildcards... from
>  2. Support dynamic destination on a <to uri=".." by using the same header from the
existing JMS component. 
>       CamelJmsDestination	javax.jms.Destination	 A destination object.
>       CamelJmsDestinationName	String	 The destination name.
>  3. I suggest making 'request-reply' be explicit, since implicit is really painful for
new users. The "magic" temp destination listener is not confusing and the user has nothing
in the route to go on as to why that is happening.
>  4. Along w/ #3, don't kill the QoS headers by default. It makes setting up proxies really
>  5. Support MQ Series 'weirdness' that current component handles.. see 'Setting JMS provider
options on the destination' here:
> Thanks!

This message was sent by Atlassian JIRA

View raw message