On Wed, Apr 11, 2012 at 10:17 PM, Castyn <eric.ben...@gmail.com> wrote:
> I am trying to trap errors thrown in camel and am running into a bit of an
> issue with nested errors.  For example:
>
> org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
>        at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:237)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:779)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1626)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream$1.run(HTTPConduit.java:1498)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:353)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_23]
>        at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_23]
>        at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
> Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
>  at [row,col {unknown-source}]: [1,0]
>        at
> com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:677)[127:woodstox-core-asl:4.1.1]
>        at
> com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:2104)[127:woodstox-core-asl:4.1.1]
>        at
> com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2010)[127:woodstox-core-asl:4.1.1]
>        at
> com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1102)[127:woodstox-core-asl:4.1.1]
>        at
> com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1125)[127:woodstox-core-asl:4.1.1]
>        at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:138)[133:org.apache.cxf.bundle:2.4.3.fuse-00-13]
>        ... 9 more
>
>
> I know I can catch this error in the camel spring DSL using something like
>
>                    <onException>
>                            
> <exception>org.apache.cxf.interceptor.Fault</exception>
>                            <redeliveryPolicy maximumRedeliveries="0" />
>                            <handled><constant>true</constant></handled>
>                            <log message="CXF Fault" loggingLevel="ERROR"/>
>                    </onException>
>
> But obviously that is a fairly generic case of a soap fault error being
> thrown by cxf, and I'd actually want to catch the more specific error, in
> this case com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog.
>
> I have tried adding an onException block for that error, but for some reason
> when I attempt to deploy it it gives me a class not found error on
> com.ctc.wstx.exc.WstxEOFException.  I have included the
> org.codehaus.woodstox/woodstox-core-asl in my POM and made sure the osgi
> bundle imports the com.ctc.wstx.exc package, but for some reason it can not
> work out this dependency.
>

That would be the ideal case to add an onException with that specify
exception type.
But yeah OSGi can be a beast to tame.

You could possible attach an <onWhen> predicate to the <onException>
and then test whether the exception class name is
Maybe something a like.

<onWhen>
   <simple>${exception.getClass().getSimpleName()} ==
'WstxEOFException'</simple>
</onWhen>

Instead of the simple you can also use use a pojo, that returns a
boolean, and then just use Exception as parameter.
Then you dont have any import for woodstock. And can check the class
name using String naming.




> Am I doing something obvious improperly?  Is there a different method I
> should go about trying to trap route errors?
>
> --
> View this message in context: 
> http://camel.465427.n5.nabble.com/Trapping-Errors-Help-tp5633932p5633932.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Reply via email to