commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: Enterprise Logging - API Proposal
Date Mon, 13 Dec 2004 19:37:56 GMT
Will move the discussion back to your proposal.

Matt Sgarlata <> wrote on 12/12/2004 
02:58:38 PM:

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

As per the earlier proposal.

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

Not sufficient.
a) Leaving the existing LogFactory alone allows a minimal implementation 
to be obtained, if that is appropriate, for Log.  It also allows an 
EnterpriseLog/LocalizedLog to be obtained.
b) Use of an alternate factory, as opposed to type-casts which might fail, 
represents a programmatic "contract".  It assures the developer that they 
*will* get an Enterprise/Localized Log class back.  Not something that may 
or may not typecase.

> 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

Agreed.  That is the intent.

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

Not sufficient.  Again, commons logging, though minimal, must be useful. 
It is trivial work for a wrapper to use the Java tools to do the message 
translation.  If the translation still fails, then agree: dump the message 

We *are* working on an assumption that
a) the component using logging *owns* the message resource bundle(s)
b) the general "scheme" for accessing/translating fits ONE paradigm, and 
said paradigm must be mappable to the target implementation [if supported 
directly], or resolved by the wrapper [if not].

> (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 :)

I argue against this.  Please keep the focus on the expected target for 
making use of commons-logging: component, not hosting 

Note that the message key resolution and message formatting must be 
directly exposed, the component developer must:

a) write the message resources: key / text
b) assume and develope to some mechanism that enables translation, or 
multiple texts per key
c) assume some formatting mechanism, and embed formatting directives in 
the messages

No matter the target environment, the extraction and formatting of these 
messages must be performed as the component developer has planned. 
Therefore, for a common I18N logging, we must assume and adopt a 
"standard" translation and formatting mechanism that all components would 

Ideally, such a standard would be supported by all, or at least a 
majority, of the target logger implementations.  Also, minimal is 
prefered.  We believe that the mechanisms provided by the JDK core 
classes, as per the original proposal, satisfy both of these.

Is this minimal?  depends on your definition of minimal.  Do I see any 
alternatives?  No.

Now, once we've settle on such, it is not a problem [and it is minimal 
work] for the wrapper classes to step in to do the translation for those 
loggers that don't do it themselves.

> Matt
> Simon Kitching wrote:
> >Hi Richard,
> >
> >The class javadoc for the EnterpriseLog class states:
> >
> >Please note that a specific implementation of Commons Logging can 
> >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 but that implementation 
> >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:
> >
> >
> > 
> >
> ---------------------------------------------------------------------
> 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