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 >
