commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Fri, 17 Dec 2004 01:56:13 GMT
Good comments, thanks.

Curt Arnold <> wrote on 12/16/2004 05:34:58 PM:

> Sorry to come in on this late.  I just read the archives after Ceki 
> posted a link on log4j-dev.
> First, I agree Enterprise is a poor name.  I tend to think in terms of

Ok.. let me make a few points:

- LocalizedLog, GlobalizeLog, i18nLog, nlsLog, nlvLog, or any of 100 other 
variants along that theme are not strictly appropriate.  I will resist 
these names.  The addition APIs include more than [admittedly not a lot 
more] i18n support.  enter/exit are new trace level [diagnostic level, 
as-per your terms] API's.

- We could consider a staged approach:
  - MoreLog extends Log  [name tbd]: for the enter/exit methods
  - nlsLog extends MoreLog: for i18n API's

Not sure I like the implications of this, but am still reluctant to add 
new methods to Log itself.

Someone suggested that for Log, it would be appropriate to make it an 
abstract class rather than an interface, so we can make these kinds of 
changes easier in the future.  I think the risks for this are low, and 
probably better [less problems for the majority of users] than just adding 
new methods to the existing interface.  Other thoughts on this direction?

Back to the issue of names, assuming we don't play some of the other games 
mentioned above, other name suggestions are welcome.

> diagnostic versus administrative logging.  Diagnostic logging intended 
> to diagnose an issue where log requests are generally discarded (unless 
> actively researching a problem) and fluency with internal program 
> structure and with the human language used in the implementation is 
> assumed.  Logger names based on class names would be appropriate here 
> since the audience is likely familiar with the code base.


JCL [as well as Log4J and JSR-47 logging] supports "trace level" [JCL 
debug, trace] logging which I believe equates to what you term "diagnostic 
logging".  We do *not* propose to 'internationalize' these... I would 
resist such efforts.

> Administrative logging (in lack of a better term, but at least it is 
> better than Enterprise) are messages intended for a difference audience 
> where knowledge of internal program structure and the human language of 
> the implementation is not given.  These difference audiences have 
> resulted in different API on some platforms, for example, Windows has 
> OutputDebugString (for diagnostic messages) and the Event log methods 
> for administrative messages.  Logger names here would likely be 
> business process related.

Reasonable, not sure if your intention is to relate this type of logging 
to the "message level" logging of JCL [fatal, error, warn, info].

> There are a couple of issues with the resource bundle proposals that I 
> have seen previously.  I haven't had time to review those presented 
> here so they may or may not apply.
> Resource bundle approaches are sufficiently demanding of developers 
> that they will likely substantially reduce the density of diagnostic 
> messages if only a resource bundle approach is available.
> Using the locale settings of the user or system is likely inappropriate 
> for diagnostic messages.  A diagnostician reviewing log files or 
> receiving networked log messages should not be forced to read log 
> messages in the user's native language.  A worse case scenario would be 
> a internationalized web site log where the language in the log file was 
> constantly changing.

Agreed.  Again, the current proposal does not provide I18N enabled logging 
for JCL debug or trace methods.

> A log request may need to be rendered for more than one locale.  For 
> example, a log request may result in email messages send to multiple 
> recipients each in an appropriate language.
> A diagnostic log may be transmitted to a location where the resource 
> bundles are not available.  If it still is resource based at that 
> point, you would require a specialized reader which would need to be 
> kept in sync as new messages were added.
> Discarded diagnostic messages need to be very low cost.  Administrative 
> messages are vastly less frequent, are rarely discarded and can be 
> fairly expensive.


> An approach that I've found to work fairly well without requiring API 
> modifications is the use of a localizing layout.
> msg00479.html) describe the use of such a layout in a project using 
> log4net.  If you were careful on how you constructed your messages (for 
> example, start with fixed content instead of variable content, did not 
> allow your conversions to be affected by the default locale), you could 
> create a fairly efficient localization mechanism by having a layout 
> that would match the "generic" message and transform it into an 
> appropriate localized content based on an external document containing 
> regex patterns and substitutions.

This is much to complex for the casual user.  To repeat earlier comment, 
it is *critical* to put JCL in it's proper role:  "enablement" for logging 
by pluggable "components".  These [sometimes small] components need to be 
plugged into something more complex [your application/framework] that 
provides the real logger.  It is not acceptable that each component tries 
to architect into itself something of the scale you appear to be proposing

Much of what you appear to be describing can be managed as follows:

a.  Take the I18N enabled EnterpriseLog [or whatever you call it]
    API's, and map them to your own EnterpriseLog implementation.

b.  Manage the "magic" as-per your application environment in your
    custom EnterpriseLog impl.

> Some of advantages of this approach: no API change is necessary, 
> diagnostic messages are still trivial to add and fast to process, each 
> appender may have a different locale, localization has no cost for 
> discarded messages, generic language (typically english) messages are 
> available for messages that have not been translated (and likely most 
> diagnostic messages would not be), does not require customized readers.

It is reasonable to attempt to "standardize" a general "enablement" for 
I18N on the API level.  Sure, you can roll your own.  Sure, each component 
could roll it's own...  Sure, we can duplicate this endlessly.  Let's 
standardize this now.

> The primary disadvantage is that is it not straightforward to ensure 
> that all the messages of concern have translations and that messages 
> that are to be localized should be designed so that they are easily 
> matched and parsed.

Any best-practices and suggestions you would like to offer on this matter 
[examples would probably be valuable] would be a welcome addition to the 

> FYI: log4cxx does have a resource bundle logging API, but I have no 
> experience with it.
> ---------------------------------------------------------------------
> 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