camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Resolved] (CAMEL-3842) keys in cxf's protocol_headers must be handled case-insenstively
Date Sun, 17 Apr 2011 15:23:05 GMT


Claus Ibsen resolved CAMEL-3842.

    Resolution: Fixed

Thanks for the patch.

> keys in cxf's protocol_headers must be handled case-insenstively
> ----------------------------------------------------------------
>                 Key: CAMEL-3842
>                 URL:
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.7.0
>            Reporter: Aki Yoshida
>            Assignee: Claus Ibsen
>             Fix For: 2.8.0
>         Attachments:
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> There was an issue in CXF, where the protocol headers were not stored in a case-insensitive
manor. This lead to the problem of not being able to find some headers or finding some headers
in duplicates at some CXF interceptors. This issue was fixed in CXF-3367 for CXF 2.3.4 and
2.4. It was fixed by not using the plain HashMap for storing the protocol headers. 
> Currently (in trunk), camel-cxf's CxfHeaderHelper and DefaultCxfBinding seem to be using
HashMap to create a new CXF's message instance and this can lead to the same issue.
> In CXF, this issue was fixed by replacing the usage of HashMap<String, List<String>)()
with that of TreeMap<String, List<String>>(String.CASE_INSENSITIVE_ORDER). This
approach was chosen over an alternative approach that converts the header names into lowercase
and store them a hashmap because there are typically a small number of entries and using a
binary search in TreeMap seems appropriate in this use case.
> I have prepared a patch for a similar change in camel-cxf's CxfHeaderHelper and DefaultCxfBinding
and also prepared some unit test cases to verify the behavior.
> Please take a look at this suggestion.
> Thanks.
> Regards, Aki

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message