Hi Willem,
>We use the .toString for the MESSAGE.PROTOCOL_HEADER serialization. >If your customer header is not that kind of header, you'd better to put >it into the Client.REQUSET_CONTEXT map. In future we will have tooling generate Spring XML representing camel route. In Spring application context XML we can simply add headers using <camel:setHeader> element. Unfortunately this does not give us control of where this header should go. We can do this programmatically but that would involve creating a custom processor just to set the custom headers before the message goes to the next endpoint. If there was a unified approach to storing headers and acting on them later then <camel:setHeader> was sufficient for handling all sorts of headers. Best Regards, Madhav Willem.Jiang wrote: > > On 1/25/11 2:43 PM, unmarshall wrote: >> >> Hi Willem, >> >> Another problem is that we cannot set an Object against a Header and rest >> assured that the object's type would be preserved. > > I didn't suggest you to do that. > >> >> There was a recent JIRA that Claus had raised as i had requested him to >> include the ability to add objects as properties/headers. The data type >> in >> properties is preserved but when it is set as a Header then toString() >> method is called on the object and the String representation of the >> object >> is stored as the header value. > > We use the .toString for the MESSAGE.PROTOCOL_HEADER serialization. > If your customer header is not that kind of header, you'd better to put > it into the Client.REQUSET_CONTEXT map. > >> >> String representation is true for most of the headers but custom headers >> might have different types which will then be acted upon either by their >> respective handlers or interceptors in case of CXF. > > If you customer interceptor can handle it, that will be good. > I don't think current camel-cxf code can do that out of box, but the CXF > interceptor framework can let you do it :) >> >> I see this as a limitation. >> >> Regards, >> Madhav >> >> >> unmarshall wrote: >>> >>> Hi Willem, >>> >>>> What kind of Custom headers do you want to put? >>>> >>>> The PROTOCOL_HEADERS is used for the CXF transport such as Http >>>> headers, >>>> JMS headers. It's unified for different DataFormat, as the message will >>>> finally send or receive from the transport layer no matter what kind of >>>> Data Format you are choicing. >>>> >>>> For the MESSAGE DataFormat, I don't think you can change the SOAP >>>> message header by setting the message header, as the SOAP message is >>>> not >>>> create by camel-cxf component when it is working in this Data Format. >>> >>> We have a custom protocol which is an extension of SOAP. This protocol >>> sets custom headers on the message. There are CXF custom interceptors >>> which are part of the interceptor chain which are registered at the Bus >>> level. When these interceptors are invoked then these custom headers are >>> looked up. However these custom headers land up in different places >>> depending on the message format. >>> >>> Now having the logic in Cxf interceptors which depends on the DataFormat >>> results in a tight coupling between Camel and Cxf which IMO not an ideal >>> way of doing things. >>> >>>> The REQUEST_CONTEXT is kind of CXF API which is used to set the >>>> customer >>>> header, and camel-cxf component just pass this context into CXF >>>> message. >>>> If you don't want other Camel components to access the this kind of >>>> customer header, you can do it in that way. >>> >>> After going through the code i had an impression that properties on >>> exchange were only stored under INVOCATION_CONTEXT under >>> REQUEST_CONTEXT. >>> The custom headers that we set never come here. >>> >>>>> >>>>> Is there a cleaner way to place the custom message headers in only one >>>>> place? >>>> Yeah, we need to think about it :) >>>> But for now, there are different level of message header that can be >>>> set >>>> into the Camel message or Camel exchange. We need to go through them >>>> and >>>> put them into different catalogs . >>> >>> One way that comes to mind is to put the headers in one place as a Map >>> or >>> some other data structure and register handler chain which can then be >>> called to act upon the message when the message is being serialized. So >>> you delay the decision of placing the headers to the last instead of >>> doing >>> that as the first step and thereby allowing clean way to access the >>> message / properties / headers via any interceptor /handler. >>> >>> Best Regards, >>> Madhav >>> >>> >>> >> > > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > > -- View this message in context: http://camel.465427.n5.nabble.com/CfxBinding-places-custom-headers-at-different-places-tp3354431p3356047.html Sent from the Camel - Users mailing list archive at Nabble.com.
