You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Nelson Minar (JIRA)" <ax...@ws.apache.org> on 2004/11/04 01:36:33 UTC
[jira] Created: (AXIS-1642) axis.development.system doesn't supress stack traces
axis.development.system doesn't supress stack traces
----------------------------------------------------
Key: AXIS-1642
URL: http://nagoya.apache.org/jira/browse/AXIS-1642
Project: Axis
Type: Bug
Components: Serialization/Deserialization
Versions: 1.2 Beta
Reporter: Nelson Minar
I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
I ran into a problem with not being able to stop stack traces from being
sent to the client even though "axis.development.system" was set to
false in the wsdd. The beauty of open source is that I've been able to
trace through the code and figure out what the problem was. The service
that I'm developing has an onFault handler that had the following line
of code:
SOAPFault fault =
(SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
Before this call, the response message contained the fault that my
service had thrown but after the call it contained a copy of the fault.
Unfortunately, the code that removes the stack trace from the fault
works on the original, not the copy, so the stack trace is still in the
response when the response gets sent.
By changing the above to:
Object fault_obj =
((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
which does not change the response message. I now simply check whether
fault_obj is an AxisFault or a SOAPFault and act accordingly.
Hope this helps others who have run into this problem.
Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1642) axis.development.system doesn't supress stack traces
Posted by "Dan Ciarniello (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1642?page=comments#action_55052 ]
Dan Ciarniello commented on AXIS-1642:
--------------------------------------
What needs to be fixed is how and when stacktraces are removed from faults. From the API documentation, it seems perfectly reasonable to call
messageContext.getResponseMessage().getSOAPEnvelope().getFault();
in Handler.onFault() when one wants to examine a fault. It is not reasonable that this call should cause stacktraces to be sent irrespective of "axis.development.system".
The problem is that a side-effect of the above call is that the response message no longer contains the original fault (an AxisFault) but a copy of the fault (a SOAPFault). When AxisServlet.processAxisFault() removes the stacktrace, it removes it from the original fault, not the copy so when the the response is serialized out to the client, it still contains the stacktrace.
The most obvious fix is to not remove the stacktrace in processAxisFault() but to remove it when the response message is serialized out.
> axis.development.system doesn't supress stack traces
> ----------------------------------------------------
>
> Key: AXIS-1642
> URL: http://nagoya.apache.org/jira/browse/AXIS-1642
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2 Beta
> Reporter: Nelson Minar
>
> I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
> http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
> I ran into a problem with not being able to stop stack traces from being
> sent to the client even though "axis.development.system" was set to
> false in the wsdd. The beauty of open source is that I've been able to
> trace through the code and figure out what the problem was. The service
> that I'm developing has an onFault handler that had the following line
> of code:
> SOAPFault fault =
> (SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
> Before this call, the response message contained the fault that my
> service had thrown but after the call it contained a copy of the fault.
> Unfortunately, the code that removes the stack trace from the fault
> works on the original, not the copy, so the stack trace is still in the
> response when the response gets sent.
> By changing the above to:
> Object fault_obj =
> ((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
> which does not change the response message. I now simply check whether
> fault_obj is an AxisFault or a SOAPFault and act accordingly.
> Hope this helps others who have run into this problem.
> Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1642) axis.development.system doesn't supress stack traces
Posted by "Chad Wilson (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1642?page=comments#action_12314127 ]
Chad Wilson commented on AXIS-1642:
-----------------------------------
Oh - and on a related note - I notice that regardless of whether you are using LogHandler or any kind of custom onFault() handling if the exception thrown has a nested exception, Axis will ignore axis.development.system and serialize the nested exception (root cause) stack trace - although correctly ignoring the main exception.
Is this the expected behaviour? This occurs whenever you throw a custom exception which sets super.rootCause:
public class MySpecialFault extends Exception {
private MySpecialFault (String customName, String customDetail, int customCode, Throwable rootCause) {
super(customName, rootCause);
this.name = customName;
this.detail = customDetail;
this.code = customCode;
}
...
}
> axis.development.system doesn't supress stack traces
> ----------------------------------------------------
>
> Key: AXIS-1642
> URL: http://issues.apache.org/jira/browse/AXIS-1642
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2 Beta
> Reporter: Nelson Minar
>
> I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
> http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
> I ran into a problem with not being able to stop stack traces from being
> sent to the client even though "axis.development.system" was set to
> false in the wsdd. The beauty of open source is that I've been able to
> trace through the code and figure out what the problem was. The service
> that I'm developing has an onFault handler that had the following line
> of code:
> SOAPFault fault =
> (SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
> Before this call, the response message contained the fault that my
> service had thrown but after the call it contained a copy of the fault.
> Unfortunately, the code that removes the stack trace from the fault
> works on the original, not the copy, so the stack trace is still in the
> response when the response gets sent.
> By changing the above to:
> Object fault_obj =
> ((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
> which does not change the response message. I now simply check whether
> fault_obj is an AxisFault or a SOAPFault and act accordingly.
> Hope this helps others who have run into this problem.
> Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1642) axis.development.system doesn't supress stack traces
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1642?page=comments#action_55029 ]
Davanum Srinivas commented on AXIS-1642:
----------------------------------------
hmmm...so what do i need to fix in Axis :)
-- dims
> axis.development.system doesn't supress stack traces
> ----------------------------------------------------
>
> Key: AXIS-1642
> URL: http://nagoya.apache.org/jira/browse/AXIS-1642
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2 Beta
> Reporter: Nelson Minar
>
> I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
> http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
> I ran into a problem with not being able to stop stack traces from being
> sent to the client even though "axis.development.system" was set to
> false in the wsdd. The beauty of open source is that I've been able to
> trace through the code and figure out what the problem was. The service
> that I'm developing has an onFault handler that had the following line
> of code:
> SOAPFault fault =
> (SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
> Before this call, the response message contained the fault that my
> service had thrown but after the call it contained a copy of the fault.
> Unfortunately, the code that removes the stack trace from the fault
> works on the original, not the copy, so the stack trace is still in the
> response when the response gets sent.
> By changing the above to:
> Object fault_obj =
> ((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
> which does not change the response message. I now simply check whether
> fault_obj is an AxisFault or a SOAPFault and act accordingly.
> Hope this helps others who have run into this problem.
> Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1642) axis.development.system doesn't supress stack traces
Posted by "Chad Wilson (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1642?page=comments#action_12314126 ]
Chad Wilson commented on AXIS-1642:
-----------------------------------
In particular this is a problem in the LogHandler that is distributed with Axis itself - in both Axis 1.2 and 1.2.1.
LogHandler's onFault() call invokes getSOAPPartAsString() on the response message, which has similar side-effects to getSOAPEnvelope.getFault() as mentioned above (just Axis 1.2.1 FINAL style).
This makes it next to impossible to run a LogHandler in a production environment (which can be a requirement for audit or debugging purposes) so is less than optimal, imho.
Two options:
* as above, make these kinds of calls on SOAPParts/Envelopes/Bodys not affect the stored AxisFault.
* fix LogHandler to be able to serialize the fault/response (for logging) without affecting the fault, in a similar way to suggested above.
This one was truly a shocker to debug! Even a comment in the web howtos on using LogHandler in prod might be useful.
> axis.development.system doesn't supress stack traces
> ----------------------------------------------------
>
> Key: AXIS-1642
> URL: http://issues.apache.org/jira/browse/AXIS-1642
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2 Beta
> Reporter: Nelson Minar
>
> I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
> http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
> I ran into a problem with not being able to stop stack traces from being
> sent to the client even though "axis.development.system" was set to
> false in the wsdd. The beauty of open source is that I've been able to
> trace through the code and figure out what the problem was. The service
> that I'm developing has an onFault handler that had the following line
> of code:
> SOAPFault fault =
> (SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
> Before this call, the response message contained the fault that my
> service had thrown but after the call it contained a copy of the fault.
> Unfortunately, the code that removes the stack trace from the fault
> works on the original, not the copy, so the stack trace is still in the
> response when the response gets sent.
> By changing the above to:
> Object fault_obj =
> ((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
> which does not change the response message. I now simply check whether
> fault_obj is an AxisFault or a SOAPFault and act accordingly.
> Hope this helps others who have run into this problem.
> Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1642) axis.development.system doesn't supress stack traces
Posted by "Chad Wilson (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-1642?page=comments#action_12355682 ]
Chad Wilson commented on AXIS-1642:
-----------------------------------
Hmm, revisiting, ignore my last comment - it is incorrect. However, the issue is still prevalent in Axis 1.3 (i.e. axis.development.system gets ignored in certain circumstances, and with the LogHandler in particular).
> axis.development.system doesn't supress stack traces
> ----------------------------------------------------
>
> Key: AXIS-1642
> URL: http://issues.apache.org/jira/browse/AXIS-1642
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2 Beta
> Reporter: Nelson Minar
>
> I had this problem in 1.2beta1, and another user just reported it on axis-user. As a convenience I'm copying his mail into a Jira bug report.
> http://marc.theaimsgroup.com/?l=axis-user&m=109952829914606&w=2
> I ran into a problem with not being able to stop stack traces from being
> sent to the client even though "axis.development.system" was set to
> false in the wsdd. The beauty of open source is that I've been able to
> trace through the code and figure out what the problem was. The service
> that I'm developing has an onFault handler that had the following line
> of code:
> SOAPFault fault =
> (SOAPFault)ctx.getResponseMessage().getSOAPEnvelope().getBody().getFault();
> Before this call, the response message contained the fault that my
> service had thrown but after the call it contained a copy of the fault.
> Unfortunately, the code that removes the stack trace from the fault
> works on the original, not the copy, so the stack trace is still in the
> response when the response gets sent.
> By changing the above to:
> Object fault_obj =
> ((SOAPPart)ctx.getResponseMessage().getSOAPPart()).getCurrentMessage();
> which does not change the response message. I now simply check whether
> fault_obj is an AxisFault or a SOAPFault and act accordingly.
> Hope this helps others who have run into this problem.
> Dan.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira