[
https://issues.apache.org/jira/browse/CAMEL-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606651#comment-13606651
]
Raul Kripalani commented on CAMEL-6180:
---------------------------------------
Hi Matt,
Regarding point #3, would you mind elaborating a bit further? Providing a small
example may help.
Thanks,
Raúl.
> 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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
