camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Commented: (CAMEL-766) Create header filter strategy that can be easily extended
Date Thu, 31 Jul 2008 18:30:00 GMT


Claus Ibsen commented on CAMEL-766:


Very good work. Makes the filtering logic of the headers coded "using the same standard".
Great work.

Looks very good. Just a comment while digging into the code/javadoc:
- DefaultHeaderFilterStrategy could the class javadoc state what "out" direction is referred
as. For completeness and not to miss understand it.
- DefaultHeaderFilterStrategy the interface methods applyFilerXXX is in the bottom of the
file. I would move the to the top. And let the properties be in the bottom.
- DefaultHeaderFilterStrategy would be nice with javadoc on the extendsXXX method that implementators
is supposed to use if needed

Maybe giving a hint in the class javadoc to see the camel-jms component for an example how
you should use it as a component developer.

Since the applyFilterXXX methods works as *excluding* headers it can be a bit confusing at
first reading the code that you use !applyFilterXXX and then add the header on a camel exchange
etc. I guess it just take a little while to get used to ;) People are not good at reading
the ! in if statements.

BTW: How many of the components are still to be of the same standard

> Create header filter strategy that can be easily extended
> ---------------------------------------------------------
>                 Key: CAMEL-766
>                 URL:
>             Project: Apache Camel
>          Issue Type: Improvement
>          Components: camel-core, camel-cxf, camel-http, camel-jetty, camel-jhc
>    Affects Versions: 1.4.0
>            Reporter: William Tam
>            Assignee: Willem Jiang
>            Priority: Minor
>             Fix For: 1.5.0
>         Attachments: patch.txt
> We have explored some ideas of how one may retreive protocol headers from of a Camel
message in this thread:
 In summary, there were two train of thoughts: 1) set aside a place for "ProtocolHeaders"
in Camel message which is strictly for storing what a component recognizes as protocol headers.
 A component can still select some or all of these protocol headers to be copied to/from the
native message header.  2) Using the current headers in Camel message and let people configure
what should be copied to/form native message.
> I thought about both approaches a bit.  I went with the later and created a patch.  I
guess the problem with the first approach is it introduces one more place to look for headers.
  We may end up forcing components examine both places for processing information.  
> In my patch, I create a HeaderFilterStrategy that can control what to copy in/out Camel
message headers.  A component can be injected with a strategy by Spring or using APIs.  I
modified the following components to use this strategy: jms, cxf, http, jetty, and jhc.  Please
review my patch and will update other components based on feedbacks.

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

View raw message