On 1/25/11 6:47 PM, unmarshall wrote:
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.
You can override the DefaultCxfBinding by putting your custom header
into the CXF message. camel-cxf component support you to set a custom
CxfBinding from URI with the option like this "cxfBinding=#bindingName ".
Then you don't need add other custom processor into the route.
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
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
