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 [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?
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
