camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randy Klingman (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-6180) SJMS Component behavior suggestions to improve upon the standard JMS component
Date Fri, 12 Sep 2014 02:29:34 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-6180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14120155#comment-14120155
] 

Randy Klingman edited comment on CAMEL-6180 at 9/12/14 2:29 AM:
----------------------------------------------------------------

Regarding #5 - I have the same request.  We ran into an issue where we needed the capabilities
provided by the sjms component (message batching and commit) but the provider destination
options - "targetClient=1" was not available.  This required us to resort to a queue specific
configuration setting on the queue - Extended-Property Control "PROPCTL(NONE)" which discarded
all the properties of a message, except those contained in the message descriptor.   

Let me know if I should open a separate issue for this specific request.  Thanks [~sabre1041]


was (Author: randy.klingman):
Regarding #5 - I have the same request.  We ran into an issue where we needed the capabilities
provided by the sjms component (message batching and commit) but the provider destination
options - "targetClient=1" was not available.  This required us to resort to a queue specific
configuration setting on the queue - Extended-Property Control "PROPCTL(NONE)" which discarded
all the properties of a message, except those contained in the message descriptor.   

Let me know if I should open a separate issue for this specific request.  Thanks

> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message