I don't know if it caused by the , can you show me the code of simpleServiceXmlBeans?
The simpleServiceXmlBeans is not my own code, it uses the following class.
Again I am getting similar results. A messages that matches the first when statement (I tested with both the route above and a version where I swapped the two xpath statements to make sure it was not dependent on the actual message) throws no errors and a call that matches the second when statement throws the Premature end of file error.
Looks like the stream from jetty is getting read to the end during the first xpath expression. Try this as a work around:
<route> <from uri="jetty:http://localhost:8084/services/simpleService"></from> <convertBodyTo type="java.lang.String"></convertBodyTo> <choice> <when> <xpath>/sim:GetCapabilitiesRequest</xpath> </when> <when> <xpath>/sim:GetMetadataRequest</xpath> </when> </choice> </route>
That worked. Thanks a lot. Is it common to have to convert your input like this in a Camel program, or is this an issue more specific to using jetty and xpath?
Glad I could help. Its really not typical to have to convert input manually; Camel usually does all this for you under the covers.
In this particular case though the message is a stream type and doesn't get reset after the first read. For these kinda scenarios we have a streamCaching() option that you can add to your route like this
which would reset the input stream at each point in the route so it could be re-read. This option does not apply to expression evaluations in the choice() processor though... it should probably be extended to support this
Current Camel 2.0-snapshot should enable the streamCaching() by default.
I just dug the code with the help of janstey's unit test. I found the expression evaluations does't reset the cached stream. So I filled a JIRA and a quick fix is coming up.