I suggest to make sure the classpath for running standable contains all the expected JARs. And if you do any tricks such as having an uber JAR or something then that can be a problem. http://camel.apache.org/how-do-i-use-a-big-uber-jar.html
On Wed, Aug 21, 2013 at 11:21 PM, clarkcb <[email protected]> wrote: > 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. -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
