commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject Enterprise Logging - API Proposal
Date Sun, 12 Dec 2004 20:58:38 GMT
To support localized log messages, we only need to introduce one 
*optional* interface that will *not* affect any existing functionality.

interface LocalizedLog extends Log { // methods TBD }

Then calling code that wants to make use of localized logging would make 
this call:

private static final LocalizedLog log = (LocalizedLog) 
LogFactory.getLog(MyClass.class);

And existing code or code that doesn't want to make use of localized 
logging stays like this:

private static final Log log = LogFactory.getLog(MyClass.class);

To accomplish this, the LogFactory implementation will be changed to 
*always* return a LocalizedLog.  If the underlying logging 
implementation supports internationalization, log messages will be 
internationalized.  If not, the LocalizedLog methods will delegate to 
the plain old Log methods and log output will display the message keys 
unresolved.  Clearly if your code is using the LocalizedLog API you will 
probably want to chose an implementation that supports localization, but 
if you don't that won't cause errors in commons-logging (your log 
messages will be written, they just won't be resolved).

This API is based on the following assumptions, which I think we should 
all be able to agree on:
(1) Commons-logging should remain a thin bridge to other logging APIs
(2) Some logging APIs already offer localized log messages (e.g. Log4J)
Which in turn implies
(3) Commons-logging will pass through localized logging calls to 
underlying logging implementations which support internationalization.  
Logging implementations which do not support localization will simply 
print out the arguments to the localized logging calls directly, without 
any resolution
(4) It is inappropriate for any type of message key resolution to be 
implemented in commons-logging.  Message key resolution is certainly 
important though, and should definitely be implemented somewhere else :)

Matt

Simon Kitching wrote:

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


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