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

-- 
View this message in context: 
http://cxf.547215.n5.nabble.com/How-to-suppress-internal-stack-traces-from-command-line-CXF-tp2263121p2263121.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to