For 3.0.. Have there been any discussions about possible improvement on how the headers and properties work across the components?
One of the common headaches is sorting through when component A -> component B, but component A is providing some incompatible headers, or headers that shouldn't be propagated. The solution ends up being clearing a bunch of headers, or resetting some headers using expressions or processors. There is a ton of great value in being able to use the headers to impact component behavior (things like CamelJMSDestinationName, etc), and we definitely don't want to lose that. It seems to boil down to: How can we strike a balance between the developer (writer of Camel routes) experience and functionality? I don't have a solution off-hand, but thought it'd make for interesting discussion. - Maybe its a policy thing? ie.. improved "namespace" of headers? Camel.Jetty.. Camel.CXF.. Camel.HTTP etc..? - Maybe components leverage Exchange properties more than message headers? - Maybe there is a special set of properties or headers reserved for Camel components to use, that get dropped by default? getComponentProperties().. - Maybe a HeaderFilterProcessor that would provide convenience functions for doing common header tasks? - Maybe just some components need to have a refresh on their header handling? Things like: <from uri="jetty:http…"/> <to uri="jetty:http.."/> .. and .. <from uri="cxf:.."/> <to uri="jetty:.."/> <from uri="jetty:.."/> <to uri="cxf:.."/> <from uri="jetty.."/> <to uri="cxfrs:.."/> <from uri="jetty:http.." /> <to uri="http4:// .. "/> It'd be really handy if the above were interchangeable (aside from payload concerns). At the same time.. <from uri="jetty.."/> <to uri="smtp .. "/> (Yikes, need to clear headers!) <from uri="jetty.."/> <to uri="jms.. "/> (I want these [x,y,z,a,b,c] headers propagated, but drop the rest.. ) Thanks, Matt Pavlovich
