axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: DO NOT REPLY [Bug 13845] - Axis logs/prints and exception when it shouldn't
Date Wed, 23 Oct 2002 04:50:38 GMT
At the very least we could downgrade stuff to info level rather than error,
though right now we cant distinguish expected from unexpected trouble.

...we used to have fatal() logging for the earth shatterers; these were the
ones that would get emailed out. They werent fatal as in 'failure of
system', but were fatal in terms of failure of request, and unexpectedly
bad. For example if the COM object's SEH wrapper caught any win32 exception
we'd return it in the return code of the wrapper app. The java code that
called the app would check the return code, if it was in the trouble range
(>=0x80000000) we'd report trouble with the complete payload of the request
as an attachment, enough to let the support team (that was me too) replicate
and fix.

Now that is app side, not axis side. Things like bad xml inbound were also
errors, and also logged to the rolling log4j logs (as you do production
side), so we could work out roughly what went wrong later. I think we even
logged execution time  & uid of requests too, for system load post-analysis.

Maybe the trick is to pull log4j.properties, move up to the xml configured
version of log4j, provide a default logger config that is distinctly
unchatty, and some examples for production that say less.

-steve




----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, October 22, 2002 18:31
Subject: Re: DO NOT REPLY [Bug 13845] - Axis logs/prints and exception when
it shouldn't


>
>
>
>
>
>   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
>
>
>



Mime
View raw message