How to suppress internal stack traces from command-line CXF?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to suppress internal stack traces from command-line CXF?

Glen Mazza
Administrator
Hello, I'm testing JAXB validation from a command-line SOAP client, with try-catch blocks to cleanly output unmarshalling/marshalling exceptions *without* having the stack trace also output.  Here's my client:

public class WSClient {
   public static void main (String[] args) {
       DoubleItService service = new DoubleItService();
       DoubleItPortType port = service.getDoubleItPort();          

       doubleIt(port, 20); // doubledNumber too large
   }
   
   public static void doubleIt(DoubleItPortType port, int numToDouble) {
       try {
          int resp = port.doubleIt(numToDouble);
          System.out.println("The number " + numToDouble + " doubled is "
              + resp);
       } catch (SOAPFaultException sfe) {
          Throwable cause = sfe.getCause();
          if (cause != null && cause.getMessage() != null) {
             System.out.println("Wrapped Exception: " + cause.getMessage());
          } else {
             System.out.println("SOAPFaultException: " + sfe.getMessage());
          }
       }
   }
}

Problem is, while CXF is properly outputting the exception text message in the catch block from the terminal window, it is still logging the full stack trace, and since I'm at a command-line window I end up getting both.  I can't seem to suppress output of this noisy stack trace:

[INFO] WARNING: Interceptor for {http://www.example.org/contract/DoubleIt}DoubleItService#{http://www.example.org/contract/DoubleIt}DoubleIt has thrown exception, unwinding now
[INFO] org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-maxInclusive-valid: Value '40' is not facet-valid with respect to maxInclusive '36' for type '#AnonType_doubledNumberDoubleItResponse'.
[INFO] at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:773)
[INFO] at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:624)
... many more lines
[INFO] at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
[INFO] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
[INFO] at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487)
... many more lines
[INFO] at client.WSClient.doubleIt(WSClient.java:23)
[INFO] at client.WSClient.main(WSClient.java:17)
[INFO] Caused by: javax.xml.bind.UnmarshalException
[INFO]  - with linked exception:
[INFO] [org.xml.sax.SAXParseException: cvc-maxInclusive-valid: Value '40' is not facet-valid with respect to maxInclusive '36' for type '#AnonType_doubledNumberDoubleItResponse'.]
[INFO] at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)
... many more lines
[INFO] at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)
[INFO] ... 22 more
[INFO] SOAPFaultException: Unmarshalling Error: cvc-maxInclusive-valid: Value '40' is not facet-valid with respect to maxInclusive '36' for type '#AnonType_doubledNumberDoubleItResponse'.

All I'd like to see is that very last SOAPFaultException: statement (last line above), which is the statement I'm explicitly outputting in my catch block.  How can I suppress the stack trace?  Metro does not have this problem, and I'd like to have CXF operate similarly if I can, namely, not to output the stack trace unless the actual catch() handler of the exception (my SOAP client in this example) explicitly requests it.  

This fix: https://issues.apache.org/jira/browse/CXF-2596 seems to sidestep the problem by allowing me to create another logger for the internal PhaseInterceptorChain-created exceptions, but this is just normal processing I don't need to log.  Should CXF-2596 be further enhanced to provide an option to *not* log stack traces by default for exceptions that end up being forwarded to user code?  Or is there another way to accomplish what I'm requesting?

Thanks,
Glen
Reply | Threaded
Open this post in threaded view
|

Re: How to suppress internal stack traces from command-line CXF?

Daniel  Kulp
Administrator

Glen,

What may be a good idea is in the PhaseInterceptorChain.doDefaultLogging
method, have it call MessageUtils.isRequestor(message).   If it's the
requestor, log at FINE.   If not, log at the current levels.

Would that work for you?    Basically, for exceptions on the server side,
there isn't a place for them to be caught and handled.  Thus, logging them to
the server log is the best thing to do.   For client side, however, they would
be re-throws so logging them probably doesn't make the most sense.

Dan


On Tuesday 03 August 2010 12:34:29 pm Glen Mazza wrote:

> Hello, I'm testing JAXB validation from a command-line SOAP client, with
> try-catch blocks to cleanly output unmarshalling/marshalling exceptions
> *without* having the stack trace also output.  Here's my client:
>
> public class WSClient {
>    public static void main (String[] args) {
>        DoubleItService service = new DoubleItService();
>        DoubleItPortType port = service.getDoubleItPort();
>
>        doubleIt(port, 20); // doubledNumber too large
>    }
>
>    public static void doubleIt(DoubleItPortType port, int numToDouble) {
>        try {
>           int resp = port.doubleIt(numToDouble);
>           System.out.println("The number " + numToDouble + " doubled is "
>               + resp);
>        } catch (SOAPFaultException sfe) {
>           Throwable cause = sfe.getCause();
>           if (cause != null && cause.getMessage() != null) {
>              System.out.println("Wrapped Exception: " +
> cause.getMessage()); } else {
>              System.out.println("SOAPFaultException: " + sfe.getMessage());
>           }
>        }
>    }
> }
>
> Problem is, while CXF is properly outputting the exception text message in
> the catch block from the terminal window, it is still logging the full
> stack trace, and since I'm at a command-line window I end up getting both.
>  I can't seem to suppress output of this noisy stack trace:
>
> [INFO] WARNING: Interceptor for
> {http://www.example.org/contract/DoubleIt}DoubleItService#{http://www.examp
> le.org/contract/DoubleIt}DoubleIt has thrown exception, unwinding now
> [INFO] org.apache.cxf.interceptor.Fault: Unmarshalling Error:
> cvc-maxInclusive-valid: Value '40' is not facet-valid with respect to
> maxInclusive '36' for type '#AnonType_doubledNumberDoubleItResponse'.
> [INFO] at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 73) [INFO] at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:6
> 24) ... many more lines
> [INFO] at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
> rceptor.handleMessage(MessageSenderInterceptor.java:62) [INFO] at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) [INFO] at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:487) ... many
> more lines
> [INFO] at client.WSClient.doubleIt(WSClient.java:23)
> [INFO] at client.WSClient.main(WSClient.java:17)
> [INFO] Caused by: javax.xml.bind.UnmarshalException
> [INFO]  - with linked exception:
> [INFO] [org.xml.sax.SAXParseException: cvc-maxInclusive-valid: Value '40'
> is not facet-valid with respect to maxInclusive '36' for type
> '#AnonType_doubledNumberDoubleItResponse'.]
> [INFO] at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamExcep
> tion(UnmarshallerImpl.java:425) ... many more lines
> [INFO] at
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(Unmars
> hallerImpl.java:360) [INFO] ... 22 more
> [INFO] SOAPFaultException: Unmarshalling Error: cvc-maxInclusive-valid:
> Value '40' is not facet-valid with respect to maxInclusive '36' for type
> '#AnonType_doubledNumberDoubleItResponse'.
>
> All I'd like to see is that very last SOAPFaultException: statement (last
> line above), which is the statement I'm explicitly outputting in my catch
> block.  How can I suppress the stack trace?  Metro does not have this
> problem, and I'd like to have CXF operate similarly if I can, namely, not
> to output the stack trace unless the actual catch() handler of the
> exception (my SOAP client in this example) explicitly requests it.
>
> This fix: https://issues.apache.org/jira/browse/CXF-2596 seems to sidestep
> the problem by allowing me to create another logger for the internal
> PhaseInterceptorChain-created exceptions, but this is just normal
> processing I don't need to log.  Should CXF-2596 be further enhanced to
> provide an option to *not* log stack traces by default for exceptions that
> end up being forwarded to user code?  Or is there another way to
> accomplish what I'm requesting?
>
> Thanks,
> Glen

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog