[
https://issues.apache.org/activemq/browse/CAMEL-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44656#action_44656
]
Claus Ibsen commented on CAMEL-766:
-----------------------------------
Hi
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: https://issues.apache.org/activemq/browse/CAMEL-766
> 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:
> http://www.nabble.com/-PROPOSAL--ProtocolMessage-to18078001s22882.html#a18078001.
> 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.
