I thought this at first, and that it was the incoming interceptor to blame for exhausting the message body (as InputStream) before it got to the unmarshalling step, but after removing the interceptors from endpoint configuration I still have the same problem.
I decided to debug both versions (running inside IDE vs. running as standalone jar), and the difference appears to be that the the IDE version succeeds in finding a fallbackConverter to convert MessageContentList to the target type (BaseTypeConverterRegistry.java:doConvertTo:...for (FallbackTypeConverter fallback : fallbackConverters)...), whereas the standalone jar version does not find a fallbackConverter and thus returns null. Why this is the case is still a mystery, but I'm going to keep digging into this. Please let me know if you have any thoughts on why fallbackConverters would be different for these cases. Thanks! -- View this message in context: http://camel.465427.n5.nabble.com/Unmarshalled-object-is-null-from-remote-WS-if-run-jar-but-not-if-run-from-inside-IDE-tp5737648p5737703.html Sent from the Camel - Users mailing list archive at Nabble.com.
