camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Accessing property on bean in header?
Date Wed, 04 Dec 2013 07:27:57 GMT
On Wed, Dec 4, 2013 at 8:22 AM, Andrew Thorburn <> wrote:
> Apologies for the spam, but this should be the last post, and I
> believe there's a bug somewhere. According the documentation
> (, I should be able to do
> something like this:
> ${in.header.type} is 'java.lang.String'
> And I will get back true or false. However, the following
> <camel:setHeader headerName="test">
> <camel:simple resultType="java.lang.Object">${in.headers[soap.header.globalRequestHeader]}
> is 'com.test.GlobalRequestHeader'</camel:simple>
> </camel:setHeader>

This is an expression and not a predicate.

You would need to set the resultType to boolean so Camel would know
its a predicate.
And not sure if Camel 2.10.x is too old to support that way.
Newer releases sure does.

> Sets the header to the following value:
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <ns2:globalRequestHeader region="UAT" version="1" xmlns:ns2="uri:com:test">
>     <uniqueId>?</uniqueId>
>     <targetSystem>?</targetSystem>
> </ns2:globalRequestHeader>
>  is ''
> OK, possibly that's due to setting it to java.lang.Object.
> I tried again, but with resultType="java.lang.Boolean" and got back
> "false", which is pretty clearly not correct. Tried a few variations
> on that, and the value on the left is always converted to a String
> before any further processing is conducted, making the "is" operator a
> bit pointless (in one case, using ${bean:camelContext}, I got a nasty
> exception, which I can share if needed). I assume this is a bug? Has
> it been fixed in a later version of Camel?
> - Andrew
> On Wed, Dec 4, 2013 at 8:03 PM, Andrew Thorburn <> wrote:
>> I should add here that I want to log the result, so I have something like:
>> <camel:log message="Message received with action
>> [${in.header.SOAPAction}], operation [${in.header.operationName}],
>> with GRH [${in.headers[soap.header.globalRequestHeader].getRegion()}]"
>> loggingLevel="INFO" />
>> But even with the following:
>> <camel:setHeader headerName="test">
>> <camel:simple resultType="java.lang.Object">${headerAs(soap.header.globalRequestHeader,
>> com.test.GlobalRequestHeader).getRegion()}</camel:simple>
>> </camel:setHeader>
>> I still get the raw XML instead of the value of the region property.
>> It basically seems that what I want isn't possible, and that even
>> thinking about using SOAP headers here was a terrible idea, given the
>> amount of pain it's caused me.
>> Thanks,
>> - Andrew
>> On Wed, Dec 4, 2013 at 7:50 PM, Andrew Thorburn <> wrote:
>>> 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

Claus Ibsen
Red Hat, Inc.
Twitter: davsclaus
Author of Camel in Action:

View raw message