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 <ne...@monkey.org> on 2001/07/22 21:40:51 UTC
one line patch, log4j, AxisFault
I've been experimenting with how the Axis client handles various kinds
of errors and came up with a few comments:
At the bottom of this message, please find a one line patch to the
current Axis CVS. It removes a call to e.printStackTrace() - stack
traces were popping up if I gave a bad hostname in my endpoint URL
and there was no way to supress them. The call to Debug.Print() should
still print the stack trace, only with the ability to override it.
Looking at the Debug class, I see the comment
// We should replace this with Log4J if we really want this stuff.
I strongly second this motion. I've been using log4j for the last year
and a half now and it's a really splendid tool. I can make a
suggestion on how to use log4j and some sample log4j patches if people
want. It integrates really nicely in libraries like this.
Finally, I think it's great that AxisFault contains all the
information about the stack trace of what generated the fault. But
would it be possible to separate it from the faultString, so I can
just get the one line description without the stack trace?
Instead of working with strings, I'd recommend modelling AxisFault as
a wrapped exception. If the AxisFault itself comes from an exception,
store the original exception as well. Wrapped exceptions are sort of a
pain in Java, but Java 1.4 finally has support for it:
http://java.sun.com/j2se/1.4/docs/guide/lang/chained-exceptions.html
Following the Java 1.4 idiom as a guideline (but not relying on having
a 1.4 JRE), I propose adding the following to AxisFault:
/** Returns the exception that is the cause of this AxisFault, or
** <i>null</i> if there was no other exception that was the cause
** of this fault.
**/
public Throwable getCause();
AxisFault(Exception) constructor would then set up the cause variable
(using Java 1.4's idiom of initCause() is as good as any way.)
AxisFault.toString() could still print the whole stack trace if folks
want. Again - the main goal is to allow client code to better pull
apart details of the fault.
Thanks,
Nelson
Re: one line patch, log4j, AxisFault
Posted by Nelson Minar <ne...@monkey.org>.
Thanks for the feedback, Glen!
>Good stuff. I agree with all your points here, except that instead of
>directly including log4j, I think we've agreed that we'll have
>everything use a common "logger proxy" interface, for which we can
>build stubs to talk to log4j, or to the internal logging APIs of
>whatever app servers end up embedding Axis.
Is this decision already made?
I'm not particularly excited about the idea - log4j is really quite a
good API all by itself and the various front-ends I've seen to it take
value away, the only thing they contribute is the hope of switching a
logging implementation someday. I prefer to work with the assumption
that if log4j ends up being a problem in the future, either rewrite
the source code (it's not hard to rewrite log4j calls with a perl
script), or build something that implements org.apache.log4j.Category
and calls your implementation. (In practice, that one class is the
only code imported in the code.)
If the group consensus is that a logging API specific to Axis is
important, I'd suggest looking at various other Apache projects,
particularly Jakarta. They have at least two abstraction APIs to log4j
already, maybe one of those would suit.
>Re: faults, I think this is just the right way to go, and that the stack
>trace should not be in the fault string, but rather in the details element.
OK, this is an easy change. Does following Java 1.4's "getCause()"
idiom sound good
>Any chance we'll see you at the IRC chat tomorrow?
I intend to be there!
nelson@monkey.org
. . . . . . . . http://www.media.mit.edu/~nelson/
Re: one line patch, log4j, AxisFault
Posted by Glen Daniels <gd...@macromedia.com>.
Hi Nelson!
Good stuff. I agree with all your points here, except that instead of
directly including log4j, I think we've agreed that we'll have everything
use a common "logger proxy" interface, for which we can build stubs to talk
to log4j, or to the internal logging APIs of whatever app servers end up
embedding Axis. Might you be psyched to help define/build such an
interface?
Re: faults, I think this is just the right way to go, and that the stack
trace should not be in the fault string, but rather in the details element.
2.2 already does this I think, including sending a serialized version of the
Fault object as well.
Thanks for the input, we'll see if we can't fix up the fault stuff ASAP.
Any chance we'll see you at the IRC chat tomorrow?
--Glen
----- Original Message -----
From: "Nelson Minar" <ne...@monkey.org>
To: <ax...@xml.apache.org>
Sent: Sunday, July 22, 2001 3:40 PM
Subject: one line patch, log4j, AxisFault
> I've been experimenting with how the Axis client handles various kinds
> of errors and came up with a few comments:
>
>
> At the bottom of this message, please find a one line patch to the
> current Axis CVS. It removes a call to e.printStackTrace() - stack
> traces were popping up if I gave a bad hostname in my endpoint URL
> and there was no way to supress them. The call to Debug.Print() should
> still print the stack trace, only with the ability to override it.
>
>
> Looking at the Debug class, I see the comment
> // We should replace this with Log4J if we really want this stuff.
> I strongly second this motion. I've been using log4j for the last year
> and a half now and it's a really splendid tool. I can make a
> suggestion on how to use log4j and some sample log4j patches if people
> want. It integrates really nicely in libraries like this.
>
>
> Finally, I think it's great that AxisFault contains all the
> information about the stack trace of what generated the fault. But
> would it be possible to separate it from the faultString, so I can
> just get the one line description without the stack trace?
>
> Instead of working with strings, I'd recommend modelling AxisFault as
> a wrapped exception. If the AxisFault itself comes from an exception,
> store the original exception as well. Wrapped exceptions are sort of a
> pain in Java, but Java 1.4 finally has support for it:
> http://java.sun.com/j2se/1.4/docs/guide/lang/chained-exceptions.html
>
> Following the Java 1.4 idiom as a guideline (but not relying on having
> a 1.4 JRE), I propose adding the following to AxisFault:
> /** Returns the exception that is the cause of this AxisFault, or
> ** <i>null</i> if there was no other exception that was the cause
> ** of this fault.
> **/
> public Throwable getCause();
>
> AxisFault(Exception) constructor would then set up the cause variable
> (using Java 1.4's idiom of initCause() is as good as any way.)
> AxisFault.toString() could still print the whole stack trace if folks
> want. Again - the main goal is to allow client code to better pull
> apart details of the fault.
>
>
> Thanks,
> Nelson
>
>
>
----------------------------------------------------------------------------
----
> ? java/build
> Index: java/src/org/apache/axis/transport/http/HTTPSender.java
> ===================================================================
> RCS file:
/home/cvspublic/xml-axis/java/src/org/apache/axis/transport/http/HTTPSender.
java,v
> retrieving revision 1.8
> diff -d -u -r1.8 HTTPSender.java
> --- java/src/org/apache/axis/transport/http/HTTPSender.java 2001/07/16
00:49:10 1.8
> +++ java/src/org/apache/axis/transport/http/HTTPSender.java 2001/07/22
19:22:56
> @@ -348,7 +348,6 @@
> }
> catch( Exception e ) {
> Debug.Print( 1, e );
> - e.printStackTrace();
> if ( !(e instanceof AxisFault) ) e = new AxisFault(e);
> throw (AxisFault) e ;
> }
>