On Wed, Dec 4, 2013 at 8:22 AM, Andrew Thorburn <nzi...@gmail.com> wrote:
> Apologies for the spam, but this should be the last post, and I
> believe there's a bug somewhere. According the documentation
> (http://camel.apache.org/simple.html), 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 'com.proaxiom.hsbc.xsd.request.GlobalRequestHeader'
>
> 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 <nzi...@gmail.com> 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 <nzi...@gmail.com> 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.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
