Showing the cause exception message on JBoss AS 7.1

[peterfry]

Hi,

I trying to work how to get a JAX-WS webservice deployed on JBoss AS 7.1 to send the full stack trace in a message response when that exception is not modeled (i.e. the service is throwing a runtime exception).

Looking at the Apache CXF documentation http://cxf.apache.org/docs/debugging-and-logging.html#DebuggingandLogging-Showingthecauseexceptionmessage

It should be possible to do something like:

<jaxws:endpoint id="server" address="http://localhost:9002/TestMessage"
     wsdlURL="ship.wsdl"

         endpointName="s:TestSoapEndpoint"

         serviceName="s:TestService"

    xmlns:s="http://test" >
      <jaxws:properties>

    <entry key="exceptionMessageCauseEnabled" value="true" /> </jaxws:properties></jaxws:endpoint>

But I've no idea how to do this in JBoss AS 7.1?

Peter.

[peterfry]

Well I have tried

         <subsystem xmlns="urn:jboss:domain:webservices:1.1">
            <modify-wsdl-address>true</modify-wsdl-address>
            <wsdl-host>${jboss.bind.address:127.0.0.1}</wsdl-host>
            <endpoint-config name="Standard-Endpoint-Config">
                <property name="faultStackTraceEnabled" value="true"/>
                <property name="exceptionMessageCauseEnabled" value="true"/>
            </endpoint-config>
            <endpoint-config name="Recording-Endpoint-Config">
                <pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
                    <handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
                </pre-handler-chain>
            </endpoint-config>
        </subsystem>

But it only seems to get some of the way i.e. the actual exception doesn't appear:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>Fault occurred while processing.</faultstring>
         <detail>
            <stackTrace xmlns="http://cxf.apache.org/fault">com.acme.webservices.security.SecureCallsHelper!validateCallInternal!SecureCallsHelper.java!239
com.acme.webservices.security.SecureCallsHelper!validateCall!SecureCallsHelper.java!84
com.acme.webservices.aspects.SecureCalls!ajc$before$uk_co_webservices_aspects_SecureCalls$1$a03a99c3!SecureCalls.java!149
com.acme.webservices.maintainmember.MaintainMemberWebService!getMemberBasicDetail!MaintainMemberWebService.java!452
sun.reflect.NativeMethodAccessorImpl!invoke0!NativeMethodAccessorImpl.java!-2
sun.reflect.NativeMethodAccessorImpl!invoke!NativeMethodAccessorImpl.java!39
sun.reflect.DelegatingMethodAccessorImpl!invoke!DelegatingMethodAccessorImpl.java!25
java.lang.reflect.Method!invoke!Method.java!597
org.jboss.ws.common.invocation.AbstractInvocationHandlerJSE!invoke!AbstractInvocationHandlerJSE.java!111
org.jboss.wsf.stack.cxf.JBossWSInvoker!_invokeInternal!JBossWSInvoker.java!181
org.jboss.wsf.stack.cxf.JBossWSInvoker!invoke!JBossWSInvoker.java!127
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1!run!ServiceInvokerInterceptor.java!58
java.util.concurrent.Executors$RunnableAdapter!call!Executors.java!441
java.util.concurrent.FutureTask$Sync!innerRun!FutureTask.java!303
java.util.concurrent.FutureTask!run!FutureTask.java!138
org.apache.cxf.workqueue.SynchronousExecutor!execute!SynchronousExecutor.java!37
org.apache.cxf.interceptor.ServiceInvokerInterceptor!handleMessage!ServiceInvokerInterceptor.java!106
org.apache.cxf.phase.PhaseInterceptorChain!doIntercept!PhaseInterceptorChain.java!263
org.apache.cxf.transport.ChainInitiationObserver!onMessage!ChainInitiationObserver.java!121
org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!AbstractHTTPDestination.java!207
org.jboss.wsf.stack.cxf.RequestHandlerImpl!handleHttpRequest!RequestHandlerImpl.java!91
org.jboss.wsf.stack.cxf.transport.ServletHelper!callRequestHandler!ServletHelper.java!169
org.jboss.wsf.stack.cxf.CXFServletExt!invoke!CXFServletExt.java!87
org.apache.cxf.transport.servlet.AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!185
org.apache.cxf.transport.servlet.AbstractHTTPServlet!doPost!AbstractHTTPServlet.java!108
javax.servlet.http.HttpServlet!service!HttpServlet.java!754
org.jboss.wsf.stack.cxf.CXFServletExt!service!CXFServletExt.java!135
org.jboss.wsf.spi.deployment.WSFServlet!service!WSFServlet.java!140
javax.servlet.http.HttpServlet!service!HttpServlet.java!847
org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!329
org.apache.catalina.core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!248
org.apache.catalina.core.StandardWrapperValve!invoke!StandardWrapperValve.java!275
org.apache.catalina.core.StandardContextValve!invoke!StandardContextValve.java!161
org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve!invoke!WebNonTxEmCloserValve.java!50
org.jboss.as.web.security.SecurityContextAssociationValve!invoke!SecurityContextAssociationValve.java!154
org.apache.catalina.core.StandardHostValve!invoke!StandardHostValve.java!155
org.apache.catalina.valves.ErrorReportValve!invoke!ErrorReportValve.java!102
org.apache.catalina.core.StandardEngineValve!invoke!StandardEngineValve.java!109
org.apache.catalina.connector.CoyoteAdapter!service!CoyoteAdapter.java!368
org.apache.coyote.http11.Http11Processor!process!Http11Processor.java!877
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler!process!Http11Protocol.java!671
org.apache.tomcat.util.net.JIoEndpoint$Worker!run!JIoEndpoint.java!930
java.lang.Thread!run!Thread.java!662</stackTrace>
         </detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

[asoldano]

The faultStackTraceEnabled=true and exceptionMessageCauseEnabled=true properties are client side props, while the endpoint-config section of the ws subsystem model is of course for server side (endpoint) configuration.

[asoldano]

You should be setting the props in the client the cxf way.

[peterfry]

But surely if the SOAP response does not contain the information then the client consuming the SOAP response won't work anyway?

Looking at

http://cxf.apache.org/docs/debugging-and-logging.html#DebuggingandLogging-SOAPFaultfordebugging

it contains the text ' ...You can let CXF server return the fault message ....' suggesting it is a server endpoint configuration property?

Thanks,

Peter.

[asoldano]

Sorry, I misread your initial message. Please let me do some tries.

[asoldano]

OK, I did a try with

            <endpoint-config name="Standard-Endpoint-Config">

                <property name="faultStackTraceEnabled" value="true"/>

                <property name="exceptionMessageCauseEnabled" value="true"/>

            </endpoint-config>

and got a soap message that's pretty much the same as yours.

The properties hand over to the cxf internals is working as the message has the the stacktrace in it, with the proper line numbers. What seems to be missing is the actual name of the exception that's been thrown. Is this what you're referring to / looking for?

[peterfry]

Yes, the actual name is what I'm after.

[asoldano]

OK, looks like a bug in CXF' generation of the soap fault detail: I'm preparing a patch locally, will create a jira for it later today and comment here.

[peterfry]

Thanks for looking at this.

[asoldano]

I've created https://issues.apache.org/jira/browse/CXF-4242

I originally thought it to be an easy fix, but it actually takes some time, so I'll get back to that later unless someone else take that in the mean time.

[peterfry]

We will probably need to revert to JBoss WS Native, how confident would you be that the issue does not exist for this implementation?

[peterfry]

I have just tried reverting JBoss-WS Native and have encountered a number of issues, I know you indicated that it isn't an easy fix but is there a hack? Could you give some indication of what needs to be built and deployed? If I know what jar needs building I might be able to implement the hack?

Thanks,

Peter.

[asoldano]

Regarding a possible hack, have a look at the description in https://issues.apache.org/jira/browse/CXF-4242 . You can hack AbstractSoapInterceptor::prepareStackTrace(..)  to include the info you need, re-build Apache CXF (possibly using the tag of the version included in you AS as a base) and copy the new jars over those you have in modules/org/apache/cxf/main. However cxf clients are going to fail processing messages with the new fault detail because they do not expect the added info. So the client side also needs fixing, likely in most of the classes that have been touched when dealing with CXF-3445.

[peterfry]

Alessio,

Thanks for the update we've decided to convert the our runtime exceptions into checked exceptions and live with the pain of converting our client code to handle these checked exceptions.

Peter.