Since no one's voiced any concerns with my proposal, why don't we go ahead and put it to a vote? I'm not a committer, but here's my +1 (and I am willing to contribute code to make this happen). We can vote on other changes separately (e.g. - add equivalent to FINER, perhaps ENTER and EXIT)
-------------------------------------------------------------------- [ ] +1 I support this API proposal and am willing to help [ ] +0 I support this API proposal but am unable to help [ ] -0 I do not support this API proposal [ ] -1 I do not support this API proposal, and here are my reasons --------------------------------------------------------------------
Matt
Richard Sitze wrote:
Interesting point Simon.. more below
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/10/2004 10:57:47 PM:
Hi Richard,
The class javadoc for the EnterpriseLog class states:
Please note that a specific implementation of Commons Logging can choose
to support either the simple logging interface (represented by [EMAIL PROTECTED]
Log}) or the advanced logging interface (represented by this
interface). A user of a Common Logging implementation that supports
only the simple logging interface will not be able to instantiate a
<code>EnterpriseLog</code>.
Given the following code:
if ((day == saturday) || (day == sunday)) { EnterpriseLog log = EnterpriseLogFactory.getLog(...); log.error("This code doesn't work on weekends"); }
are you proposing that this code will run fine all week, then suddenly
throw a runtime error on saturday if the underlying log implementation
does not support "enterprise" logging?
As you noted below, the desired behavior is that logging will always succeed. If I recall correctly, the current JCL will fall back to a SimpleLogger if it cannot locate an explicitly configured Log implementation. Two points worth considering on this topic:
1. Fall back is "ok", BUT - we *MUST* log an error/info/warning message on this event, so that there is a clear understanding that something is not as it should be. The "silent fail & fallback" of the current JCL has to go.
2. A "simple" EnterpriseLog implementation must be made available, to allow the behavior you describe below.
While this example is a bit contrived, I can certainly envisage an app put together with modules, one of which uses "enterprise" logging, and is only invoked under some conditions...
Incidentally, it looks like JCL itself will throw an exception on startup if an explicit log implementation is specified (eg via system properties or commons-logging.properties) but that implementation cannot be found. This is quite in contradiction to the log4j logging approach, which is that an app should *never* fail just because logging fails. I prefer the log4j philosophy myself...
Regards,
Simon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
******************************************* Richard A. Sitze IBM WebSphere WebServices Development
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
