[
https://issues.apache.org/jira/browse/CAMEL-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-6180.
--------------------------------
Fix Version/s: (was: Future)
3.x
Resolution: Fixed
We have overhauled the sjms components recently to be similar to jms
> SJMS Component behavior suggestions to improve upon the standard JMS component
> ------------------------------------------------------------------------------
>
> Key: CAMEL-6180
> URL: https://issues.apache.org/jira/browse/CAMEL-6180
> Project: Camel
> Issue Type: Improvement
> Components: camel-sjms
> Reporter: Matt Pavlovich
> Assignee: Scott England-Sullivan
> Priority: Major
> Fix For: 3.x
>
>
> 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 jms:queue:US_TICKETS_*
> 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 complicated.
> 5. Support MQ Series 'weirdness' that current component handles.. see
> 'Setting JMS provider options on the destination' here:
> http://camel.apache.org/jms.html
> Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)