[jira] Resolved: (CAMEL-1212) Improve JMS header name endocing/decoding strategy

["Claus Ibsen (JIRA)" <ji...@apache.org>]

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

Claus Ibsen resolved CAMEL-1212.
--------------------------------

    Resolution: Fixed

Committed revision 756479.

See the new option "jmsKeyFormatStrategy*.

However Camel will now also by default be able to transfer the hyphen char (eg so Content-Type) should be preserved.



> Improve JMS header name endocing/decoding strategy
> --------------------------------------------------
>
>                 Key: CAMEL-1212
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1212
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-jms
>    Affects Versions: 1.5.0
>            Reporter: Jason Royals
>            Assignee: Claus Ibsen
>             Fix For: 2.0.0
>
>
> We have a scenario where we need to perform the following style of integration:
> {code}
> HTTP -> JMS -> HTTP
> {code}
> The final HTTP endpoint needs to receive the headers as they were in the original HTTP request.  However, I am finding that the HTTP headers that contain a hyphen (such as Content-Type, Content-Length etc) are being omitted when the messages go onto the queue.  
> {{JmsBinding}} has two static methods to perform some basic header manipulation to "encode" and "decode" headers that are not valid Java identifiers.  However, the strategy employed does not handle hyphens or other illegal characters, only periods.  Secondly, as static methods they cannot be overridden by my own extension of {{JmsBinding}}.  And finally, {{JmsHeaderFilterStrategy}} has a static link back to these methods in {{JmsBinding}} so that makes it hard to replace.
> To me, it would be more appropriate that {{HeaderFilterStrategy}} implementations should actually contain the code to
> # Advise if a header needs to be encoded/decoded, which it already does, but in addition;
> # Actually perform that encoding/decoding in it's own implementation-specific way
> This affects 1.5.0 but it's also in the trunk like this.
> I have a workaround which is a little messy but it works :-)
> Thanks,
> Jason

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