camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-6807) Message headers with uppercase letters not matched by jxpath
Date Thu, 03 Oct 2013 10:31:42 GMT


Claus Ibsen commented on CAMEL-6807:

Thanks for reporting. Do you mind working on an unit test as well?

> Message headers with uppercase letters not matched by jxpath
> ------------------------------------------------------------
>                 Key: CAMEL-6807
>                 URL:
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.10.4
>         Environment: JXPath used as Expression language
>            Reporter: Petr Janata
>         Attachments:
> {{DefaultMessage}} uses {{CaseInsensitiveMap}} for storing headers. If header name contains
uppercase characters, then jxpath expression with correct case will not match.
> E.g. header named _fooBarBaz_ on "in" message will not be matched by following jxpath
> {code:xml}
> <jxpath>/in/headers/fooBarBaz = something</jxpath>
> {code}
> JXPath evaluates nodes that match the fooBarBaz name and uses the keySet() to obtain
candidates. The problem is that CaseInsensitiveMap.keySet() returns the converted internal
keys, instead of the original keys.
> *Is it possible to override the keySet() method of CaseInsensitiveMap to return the original
keys?* Then a user will not be unpleasantly surprised that his key is not in the key set.
> {|borderStyle=solid}
> @Override
> public Set<String> keySet()
> {
>     return originalKeys.values();
> }
> {code}
> There are two workarounds possible but neither of them is nice in my eyes.
> # use only lowercase header names
> # register custom DynamicPropertyHandler in JXPath
> Ad 1. this probably wasn't the intention. User must rely on implementation of private
method {{CaseInsensitiveMap.assembleKey()}}. This then defeats the purpose of case insensitiveness.
> Ad 2. custom property handler must be registered via {{JXPathIntrospector.registerDynamicClass()}}
"in the start", e.g. before anybody calls {{JXPathIntrospector.getBeanInfo()}}. In our projects
it was enough to declare an extra eagerly-instantiated singleton Spring bean.
> {code:xml}
> <bean class="CaseInsensitiveMapPropertyHandler"
> 		init-method="init"
> 		autowire-candidate="false"
> 		lazy-init="false" />
> {code}

This message was sent by Atlassian JIRA

View raw message