Bug 1111744

Summary: [GSS] (6.4.0) Add exception name to faultstring/detail/stackTrace
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Kyle Lape <klape>
Component: Web ServicesAssignee: Rebecca Searls <rsearls>
Status: CLOSED CURRENTRELEASE QA Contact: Rostislav Svoboda <rsvoboda>
Severity: medium Docs Contact:
Priority: urgent    
Version: 6.3.0CC: asoldano, jbliznak, jclere, kkhan, myarboro, rsearls
Target Milestone: ER1   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1168630    

Description Kyle Lape 2014-06-20 22:11:51 UTC
Description copied from CXF-4242:

When using faultStackTraceEnabled = true and exceptionMessageCauseEnabled = true, it would be nice have the soap message enriched with the exception that caused a fault to be generated. The stackTrace element, though, does not include the (class) name of the exception that's been thrown.

Comment 4 Rebecca Searls 2014-07-31 20:34:52 UTC
The printing of the error information is provided by 
org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor
and 
org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptor
These 2 interceptors are explicitly set in 
org.apache.cxf.binding.soap.SoapBindingFactory
Currently there is no convenient way for JBossws to submit its own
classes for use.  We would need to either provide a CXF patch for the
minor change to the existing Soap11FaultOutInterceptor and Soap11FaultOutInterceptor
or provide a patch that provides a way for JBossws to submit its own classes for use.   

Is this enhancement important enough to the end-user to submit a patch of either 
type to CXF?

Comment 5 Kyle Lape 2014-08-05 22:45:04 UTC
> Is this enhancement important enough to the end-user to submit a patch of either 
type to CXF?

Probably not.  If they were to submit a patch themselves, then there would be no need to involve Red Hat :).

I was thinking it would be simpler (and more generally useful) to patch CXF directly without any need for JBossWS to override the behavior.

Comment 7 Rebecca Searls 2014-11-11 14:47:30 UTC
It has been confirmed that in CXF 3.0.1 provides the full stackTrace (
i.e. including the exception that caused a fault to be generated).
Test, org.jboss.test.ws.jaxws.cxf.jbws3813.JBWS3813TestCase, was added to jbossws
(JBWS-3813) to validate this.  see 
https://svn.jboss.org/repos/jbossws/stack/cxf/trunk (version: 5.0.0-SNAPSHOT)
Committed revision 19086.

Comment 8 Rebecca Searls 2014-11-11 16:58:48 UTC
I have tested jboss-as-7.5.0.Final-redhat-SNAPSHOT which to my understanding is the base for eap 6.4.0.  This version is using cxf: <version.org.apache.cxf>2.7.13</version.org.apache.cxf> and 
jbossws/stack/cxf/tags/jbossws-cxf-4.3.2.Final
<version.org.jboss.ws.cxf>4.3.2.Final</version.org.jboss.ws.cxf>

This issue is NOT resolved with this version combination.

jbossws-cxf-4.3.2.Final was branched (2014-04-29 09:13:36  (r18595)) before
the needed code changes in org.jboss.wsf.stack.cxf.configuration.ServerBeanCustomizer were checked in to
https://svn.jboss.org/repos/jbossws/stack/cxf/trunk.

 1. The relevant code changes from jbossws/stack/cxf/trunk need to be backported
      to jbossws-cxf-4.3.2.Final. 
 2. The test case check-in https://svn.jboss.org/repos/jbossws/stack/cxf/trunk
     (version: 5.0.0-SNAPSHOT) Committed revision 19086  should be pulled as
      well.
 3. The fix for https://issues.jboss.org/browse/JBWS-3854 is also needed.

Comment 9 Alessio Soldano 2014-11-12 15:42:40 UTC
For the records: I've talked with Rebecca about the comment above, clarifying that the changes she's mentioning (the ServerBeanCustomizer ones as well as the JBWS-3854 ones) are actually not strictly required for solving this issues, as they're only additional means of setting up the 2 cxf properties required for enabling exception details in the soap faults.

What's relevant here is the actual exception data coming from CXF; that is being evaluated / checked as I have some tests that seem to prove CXF-4242 is actually not solved yet. Rebecca is investigating.

Comment 11 Jan Blizňák 2015-01-15 11:56:35 UTC
Verified on 6.4.0.ER1

Comment 12 JBoss JIRA Server 2015-04-25 20:26:38 UTC
Alessio Soldano <asoldano> updated the status of jira JBWS-3813 to Closed