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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 > > >
