Hi,
probably it's best to "marshal" to a generic XML Document, for example
org.w3c.dom.Document
exchange.getIn().getBody(Document.class)
Or try to run an XPath expression on the body and decide to which class you
need to unmarshal the body.
Sorry, don't have an example at hand yet.
Regards, Michael
Am 25. Juni 2019 18:10:00 MESZ schrieb Ron Cecchini <roncecch...@comcast.net>:
>Unfortunately, I can't.
>
>The device I'm listening to sends a mix of "Status" and "Data" messages
>over the same UDP port.
>
>I've been trying to implement the strategy I alluded to, using
>doTry/doCatch to try unmarshalling as one message type, and then the
>other ... but things have gotten gnarly:
>
>I first solved the problem having to do with the Camel Java DSL not
>handling nested doTry blocks very well. (I broke up the route, used
>some "direct" routes, etc.)
>
>Ok, fine.
>
>The problem I've been banging my head on *now*, though, is the fact
>that it *seems* that trying to do the first unmarshal() blows away any
>properties I set on the exchange! What the heck...
>
>In other words:
>
>When I first get something off the wire (the message over UDP), I save
>a copy of the body:
>
> .setProperty("bodyCopy", body())
>
>Here's the first bit of processing. I've added a bunch of logging.
>In the log statement immediately before the unmarshal, the 'bodyCopy'
>is there.
>Immediately after the unmarshal, it's gone.
>
> .doTry()
> .log("doTry: BEFORE unmarshal - bodyCopy: ${property[bodyCopy]}")
> .unmarshal(dataMessageFormat)
> .log("doTry: BEFORE process - bodyCopy: ${property[bodyCopy]}")
> .process(new DataMessageProcessor())
> .doCatch(Exception.class)
>.log("*** ERROR: couldn't unmarshal or process Data Message; will try
>as Status Message")
> .log("about to setBody - bodyCopy: ${property[bodyCopy]}")
> .setBody(exchangeProperty("bodyCopy"))
> .to("direct:tryStatusMessage")
>
>I found only one other person reporting something similar, back in
>October 2018:
>
>http://camel.465427.n5.nabble.com/Apache-Camel-JAXB-unmarshalling-returns-null-properties-after-upgrade-from-Camel-from-2-20-4-to-2-211-tt5824549.html
>
>The recommendation was to downgrade the version of 'jaxb-impl' being
>used -- which I'm not using.
>
>FWIW, I created this project from the Camel Spring Boot archetype,
>which is setting the Camel version at 2.21.1. I'm using
>'camel-jaxb-starter' for my JAXB, and I wasn't specifying a version.
>As a test, I tried changing the 'camel-jaxb-starter' version to several
>things, going all the way back to version 2.18.0, but that didn't solve
>my problem.
>
>Strange.....
>
>I'm going to have to come up with some other trick to hang on to the
>body - so that I can reset the body - so that I can attempt the 2nd
>unmarshal.
>
>Wish me luck....
>
>> On June 25, 2019 at 9:50 AM Michael Davis <michael.da...@solace.com>
>wrote:
>>
>>
>> Can you get the sender to specify which type of file it is using a
>particular topic or message header or something?
>>
>> Michael Davis
>>
>> On 2019-06-21, 5:29 PM, "Ron Cecchini" <roncecch...@comcast.net>
>wrote:
>>
>> Hey, all.
>>
>> I have a route that's sitting on a port and it can receive 1 of 2
>different XML messages.
>>
>> I was simply going to try to unmarshal with the first one, and if
>it errors, unmarshal with the next one.
>>
>> But is there a smarter or best practices way to handle this?
>>
>> Thanks.
>>
>>
>>
>>
