Well, we can do as little as asking people not to put unwanted characters
into the property name or as far as extending Camel Message class as
follows:
- add new ctor: Message(Message delegate)
- each Camel Message derived class would override getHeader(String name)
method which might look like this:
public Object Message.getHeader(String name) {
Object value == null;
if (delegate != null) {
value = delegate.getHeader(name);
}
if (value == null) {
value = getHeaders().get(name);
}
if (value == null) {
value = getDerivedHeader(name);
}
return value;
}
public Object XYZMessage.getDerivedHeader(String name) {
String wireName = prohibitedToSubstituteCharacterMap.replace(name);
...
extract and return header value using wireName from the component's
native message
...
}
public XYZMessage.writeHeaders() {
Object value = null;
for (String name = getHeaderNames()) {
value = getHeader(name);
String wireName =
prohibitedToSubstituteCharacterMap.replace(name);
...
create component's native message
set header value using wireName to the component's native
message
...
}
}
Claus Ibsen wrote:
>
> Hi
>
> CAMEL-653 got me triggered, as the bean component is one of the greatest
> feature in Camel - that its so well integrated with the POJO programming
> model.
> https://issues.apache.org/activemq/browse/CAMEL-653
>
> And this issue as also for the file headername that is also a pain in the
> a** for end-users
>
> However end-users use JMS to send exchanges and we lose headers as the
> header keys are not valid according to the JMS spec so they are removed in
> a filter.
>
> We have some issues reported on this already:
> http://issues.apache.org/activemq/browse/CAMEL-239
> http://issues.apache.org/activemq/browse/CAMEL-227
>
> I am wondering if we can do something for 1.4?
>
> I have this simple strategy that when an message is sent over the JMS wire
> its header keys that have (dots) in their name is replaced with a valid
> character such as underscore.
>
> Then org.apache.camel.MethodName is sent over as
> org_apache_camel_MethodName and then when there is a lookup for a property
> on the JmsMessage (Camel class) then we use the decoded safe key to look
> for org_apache_camel_MethodName when the input was the original key
> (org.apache.camel.MethodName). We could also try to restore the original
> key names on the Jms message itself when Camel consumes the message.
>
> Using this we are able to preserve method name for the bean component and
> the filename for the file component. Or just test if the key starts with
> "org.apache.camel" then we should be more safe for the future.
>
>
> Another strategy is to only cater specially for the File and Bean
> component to preserve its MethodName and FileName properties? Then we will
> be able to restore the keys with the original name on the underlying
> JmsMessage.
>
> Any thoughts on this?
>
>
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
>
>
--
View this message in context:
http://www.nabble.com/Preserving-JMSHeaders-for-Bean-and-File-component-%28and-potentially-others-as-well%29-tp18231298s22882p18244881.html
Sent from the Camel - Development mailing list archive at Nabble.com.
