commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject [VOTE] [logging] Enterprise Logging - API Proposal
Date Mon, 13 Dec 2004 18:11:30 GMT
The API I proposed yesterday circumvents this problem and allows us to 
add whatever methods we need for internationalization while not breaking 
backwards compatability.  Instead of adding methods to the Log 
interface, we introduce a new interface, called "LocalizedLog".  The key 
is that the Log and LogFactory APIs can remain unchanged and yet still 
allow us to introduce this new functionality.

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 <s_kitching@paradise.net.nz> 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 {@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 
>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>    
>>
>
>*******************************************
>Richard A. Sitze
>IBM WebSphere WebServices Development
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message