Personally, I'd like there to be just one type of message logged by Axis
- serious, earth shattering, system errors. Basically things that an Admin
guy would need to know about. Those should be placed in whatever logging
mechanism has been defined (default to axis.log or something like that).
Any other error would then be the kind that is generated as a result of
data from a client (like the one mentioned in the bug report) and those
should be sent back to the client and not logged by the Axis engine.
Notice that in this setup any exception generated by non-axis code would be
caught (by axis), converted to an AxisFault and sent back to the client -
no logging needed. Any exception generated by axis code should _log
itself_ because it is the only one that knows how serious it is,converted
to an AxisFault and sent back to the client. So, in short, the code that
throws the exception should be responsible for determining if it should be
logged or not (ie. is this "earth shattering") - not the catcher.
A side issue is how to deal with debugging messages and what type of
switching mechanism should be used but I view that as a different
discussion (even if it turns out to piggy-back on the logging mechanism).
Get the non-debugging message right first, then worry about debugging ones.
-Dug
"Steve Loughran" <[EMAIL PROTECTED]> on 10/22/2002 08:03:25 PM
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: DO NOT REPLY [Bug 13845] - Axis logs/prints and
exception when it shouldn't
----- Original Message -----
From: "Richard Sitze" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 22, 2002 4:11 PM
Subject: Re: DO NOT REPLY [Bug 13845] - Axis logs/prints and exception when
it shouldn't
> (bugzilla down...)
Ok, I thought it was me, our network is playing up today. with 1 ping in 3
to my mailserver dropping out.
>
> Don't forget about our "enterprise" level logging. It's not clear to me
> that this particular situation applies.. but it's out there if it does.
We need to look at logging in general. I've just been tweaking the
AxisServlet so that when the development property is set
(axis.development.system) , then we do return a stack trace on invalid
WSDL,
but even that isnt enough to help me track down why the WSDL is broken.
So in this case we need more diagnostics, not less.
The big issues we have with exceptions right now are
1. we dont distinguish between 'valid' exceptions from the invocation, and
unexpected faults, hence the bugrep.
2. the body of axis faults created by wrapping other exceptions, often
contains stack traces that we dont want to get out to the caller.
Really we need to
-keep stack trace info separate and private at production time
-distinguish endpoint originated exceptions from other exceptions, and not
log the endpoint ones
How can we go about doing this?
