I've been having a bunch of trouble trying to do something that seems
like it should be really simple... Using Camel 2.10.7 on ServiceMix
4.5.2.
Basically, I'm sending a SOAP message, which contains a SOAP header
that looks like this:
<uri:globalRequestHeader region="?" version="?">
<requestDateTime>?</requestDateTime>
<uniqueId>?</uniqueId>
<targetSystem>?</targetSystem>
</uri:globalRequestHeader>
Camel takes the bean from a CXF Endpoint in Payload format, and then
adds the SOAP headers to the Exchange Headers. In this case, the SOAP
header is being marshalled via JAXB before being added to the Exchange
Headers (so it's put into the headers as an object).
I now have a com.test.GlobalRequestHeader object in my exchange
headers, and want to access the property region, say.
How do I do this?
I've tried ${headerAs(soap.header.globalRequestHeader,
com.test.GlobalRequestHeader).region} and that doesn't work. I've
tried a bunch of other ways of doing in via Simple, and it just does
not work. Checking TRACE logs, I see that it's always being converted
to a String, instead of having methods called on it, which is a bit
strange. Is it possible that the fact that it's a JAXB-annotated class
is interfering with the Simple language somehow?
I can definitely access the header, because I see the XML being
written out to the log, but I don't want the goddamn XML, I want the
value of the property. But no matter how I try, all I see in the log
is the header objected converted to XML, not the value of the
property.
I have tried the following expressions:
[${headerAs(soap.header.globalRequestHeader,
com.test.GlobalRequestHeader).getRegion()}]
[${headerAs(soap.header.globalRequestHeader,
com.test.GlobalRequestHeader).region}]
[${in.headers[soap.header.globalRequestHeader].region}]
[${in.headers[soap.header.globalRequestHeader].getRegion()}]
The first two put out XML in the log. The second two put out null /
the empty string.
I really hope I'm missing something, because it doesn't seem like it
should be this hard to access a single property on a header object.
The alternative, I guess, would be to pipe the object through another
processor and set all the properties as individual headers, which
seems a bit absurd, frankly.
Thanks,
- Andrew
