commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: Enterprise Logging
Date Mon, 13 Dec 2004 17:33:30 GMT
Interesting point Simon.. more below

Simon Kitching <> wrote on 12/10/2004 10:57:47 

> 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 {@link
> 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 

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 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:
> For additional commands, e-mail:

Richard A. Sitze
IBM WebSphere WebServices Development

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message