Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <18F84C6B-4FBB-11D9-A60E-000D936D12D0@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: commons-dev@jakarta.apache.org
From: Curt Arnold <carnold@apache.org>
Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date: Thu, 16 Dec 2004 17:34:58 -0600

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

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.

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.

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.
http://www.mail-archive.com/log4j-user@logging.apache.org/ 
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.

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.

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.

FYI: log4cxx does have a resource bundle logging API, but I have no  
experience with it.


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