Bug 1111744 - [GSS] (6.4.0) Add exception name to faultstring/detail/stackTrace
Summary: [GSS] (6.4.0) Add exception name to faultstring/detail/stackTrace
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
urgent
medium
Target Milestone: ER1
: EAP 6.4.0
Assignee: Rebecca Searls
QA Contact: Rostislav Svoboda
URL:
Whiteboard:
Depends On:
Blocks: 1168630
TreeView+ depends on / blocked
 
Reported: 2014-06-20 22:11 UTC by Kyle Lape
Modified: 2019-08-19 12:45 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA CXF-4242 0 None None None Never
Red Hat Issue Tracker JBWS-3813 0 Minor Closed Add exception name to faultstring/detail/stackTrace 2015-10-08 16:26:51 UTC

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


Note You need to log in before you can comment on or make changes to this bug.