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>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41BDFB01.4030304@users.sourceforge.net>
Date: Mon, 13 Dec 2004 15:26:41 -0500
From: Matt Sgarlata <sgarlatm@users.sourceforge.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: Enterprise Logging - API Proposal
References: 
 <OFA8294C85.92B680BD-ON86256F69.0069101C-86256F69.006BD7D5@us.ibm.com>
In-Reply-To: 
 <OFA8294C85.92B680BD-ON86256F69.0069101C-86256F69.006BD7D5@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>>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.
>  
>
I advocate that the type cast above *never* fail, because LogFactory 
will (in JavaDoc, not in its actual interface) guarantee a LocalizedLog 
will be returned.  If the underlying logging implementation doesn't 
support internationalization, then the messages are just passed through 
unresolved.  I will argue why I like this approach below...

>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 
>directly.
>
>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 
>application/framework.
>
>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 
>use.
>
>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.
>  
>
Ah but I do see alternatives : )

First, I'm sure everyone will agree: messages should be parameterizable 
in this standard format shown below.

messageKeyNumberOne=This is an {0} message from {1}

So I can plug in "ignorant" and "Matt" or "insightful" and "God", as the 
case may be.

The goal of "standardizing on a format" is satisfied just by what I have 
written previously.  There is no need to specify any mechanisms for 
retrieving the message template based on a key like 
"messageKeyNumberOne".  That retrieval could happen through the file 
system or a database or whatever.  I do think that *falling back* on the 
java.util.ResourceBundle functionality is a valid approach, but we need 
to take account the case when that resolution doesn't work (e.g. - I am 
pulling my resource from a DB instead, but haven't configured that 
yet).  If java.util.ResourceBundle fails, we have to be prepared to pass 
unresolved messages straight through to the underlying logging system.  
I'm pretty sure the Commons team will agree that throwing an exception 
is not an option.  Commons logging already made the choice that broken 
logging will *never* bring a system to its knees (if someone disputes 
this, please start a new thread).

So if java.util.ResourceBundle fails, I think we have two alternatives:
A. Pass unresolved messages to the underlying logging implementation if 
the implementation doesn't support internationalization.  This is the 
approach I advocated before.  I still think it's reasonable because if 
you want internationalization of your log messages, I think you should 
pick a logging implementation that supports it!  However, (B) below may 
be a better, more middle-of-the-road alternative:
B.  Define an interface similar to Spring's MessageSource 
(http://www.springframework.org/docs/api/org/springframework/context/MessageSource.html) 
interface.  That way, people can plug in whatever resource bundle 
implementation they want to use (java.util.ResourcesBundle directly, 
Struts'  resource bundle mechanism, Commons Resources, Spring, to name a 
few).  This allows you to mix-and-match logging implementations and 
message key resolution implementations.

A is more minimal, B is more functional.

Matt


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