camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Issue with JMS endpoint & headers that do not conform to JMS spec
Date Mon, 13 Aug 2012 07:22:16 GMT

Its documented on the Camel JMS page about the JMS spec limitations on
header keys / header value types etc

Also see the option jmsKeyFormatStrategy where you can provide a custom strategy

On Wed, Aug 1, 2012 at 4:59 PM, Ignat <> wrote:
> Hello,
> I think I've run into certain issue with camel - normally it allows almost
> any header names, but JMS spec is quite restrictive about it (taken from JMS
> 1.1 paragraph, page 42):
> Identifiers:
> - An identifier is an unlimited-length character sequence that must begin
> with a Java identifier start character; all following characters must be
> Java identifier part characters. An identifier start character is any
> character for which the method Character.isJavaIdentifierStart returns true.
> This includes ‘_’ and ‘$’. An identifier part character is any character for
> which the method Character.isJavaIdentifierPart returns true.
> - Identifiers cannot be the names NULL, TRUE, or FALSE.
> ..... (formal naming rules about reserved identifiers are skipped) ...
> So, for example, Foo://Bar&baz is valid header for using within camel route,
> but it won't pass JMS provider validation for identifier correctness.
> This issue is hidden in Camel to certain degree, since identifiers like
> foo-bar will be auto-magically transformed into foo_HYPEN_bar, but this
> transformation does not affect whole range of possible values.
> My current workaround is to actually strip all message's headers that do not
> conform to quoted spec, but some policy of auto-magical header's
> transformation (from incoming messages and for outgoing messages) could be
> potentially useful.
> For some reason I cannot find any code in camel trunk that ignores header
> names that are not conforming to be java identifiers (looked into
> shouldOutputHeader and
> and DefaultHeaderFilterStrategy) so I presume this is just an oversight.
> Also current behaviour contradicts to
> Message Header Mapping wiki section.
> Thanks.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message