Had another crack at this, and my ultimate problem was that I didn't
read the documentation carefully enough - I can do what I want, just
not how I wanted to do it.
What I wanted to have was a property called "a.b.c", and then be able
to call an OGNL expression on it. I had thought I could do it by using
the following fashion to get a header: in.headers[a.b.c].OGNL - that
does not work, and the documentation does not list that as a
possibility - OK, that's my bad, and I'll raise a feature request if I
want to see supported.
The other way I had initially tried, which had not worked, was
in.headers.a.b.c.OGNL - if I want to use an OGNL expression to access
a header property, I cannot have a '.' in the name of the header.
That's something I feel the documentation could be clearer on, though
it never said my way would work, and after a bit of though I'm not
surprised that it doesn't work.
Anyway, I can do what I want, I just have to name my header
soap_header_* instead of soap.header.* (or what have you - just so
long as the header name does not contain a period). Case closed.
Thanks,
- Andrew
On Thu, Dec 5, 2013 at 2:15 PM, Andrew Thorburn <nzi...@gmail.com> wrote:
> Something is broken here - not sure if it's me or Camel, but I can't
> say that I expected that,given the following:
>
> setHeader("test").simple("${in.header.simpleBean} == null",
> Boolean.class).setHeader("test2").simple("${in.headers.simpleBean} !=
> null", Boolean.class)
>
> *Both* headers are false! This is using Camel 2.12.2, so the latest
> version. The full output and code is here:
> http://pastebin.com/xdSsatEP, and it's pretty simple, so if someone
> could explain what I'm doing wrong that would be awesome.
>
> The header, simpleBean, is definitely not null - that's confirmed in a
> log message and by actually checking the header in another processor,
> so I think something has gone horribly wrong in Camel... I also still
> can't extract properties from header objects, so I'm assuming that's
> not supported.
>
> Thanks,
>
> - Andrew
>
> On Wed, Dec 4, 2013 at 8:36 PM, Andrew Thorburn <nzi...@gmail.com> wrote:
>> Yes, I did eventually figure that out, and when I did, the predicate returns
>> false due to the left-hand side being converted to a String before the
>> comparison takes place. Given that it's probably a bug, is it likely fixed
>> in a later version of Camel? I'll try to check it myself, probably in a day
>> or so.
>>
>> - Andrew
>>
>> On 4/12/2013 8:28 PM, "Claus Ibsen" <claus.ib...@gmail.com> wrote:
>>>
>>> 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
