commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [Logging] Internationalization enhancement proposal
Date Fri, 21 Feb 2003 16:05:52 GMT
Adding 24 methods and the requirement that the logger deals with
internationalization doesn't seem right. The second part is worse - 
each app uses different styles of ResourceBundles - and you mix 
very different domains.

A much simpler solution - with no API change in Log - is to 
use the fact that the message is an Object, and define conventions
for what it should be for "internationalized" messages.
For example, add a "I18NMessage" class that holds message and params - 
and has a toString() method that returns something printable.

Then add a second class that deals with I18N - I don't think the right
place is logging ( again - this is a complex issue ), but some helper
could be included in logging as long as it doesn't impose too many 
restrictions on how the ResourceBundles are organized. 

I know some people preffer to use message IDs (ints), some use XML files,
and so on.

Another alternative: create a separate interface ( in a i18n component )
that uses Log for the actual display of the message. 

Implementing 24 methods ( even if it is cut&paste ) doesn't seem like fun.


Andrew McConnell wrote:

> I would like to propose that a number of methods be added to the Log
> interface to meet the suggestion outlined in the commons-logging user
> guide: "Perhaps more direct support for internationalizing log messages
> can be introduced in a future or alternate version of the Log interface"
> It seems to me that the JDK1.4 logging support for i18n is an excellent
> model.
> To implement, a single overloaded getInstance() method needs to be added
> to LogFactory so that a resource bundle can be associated with a Log.
> Several methods would need to be added to the Log interface to provide a
> way to pass parameters to the resource bundle for rendering. For
> example, for trace-level messages, add:
> trace(Object message, Object param);
> trace(Object message, Object[] params);
> trace(Object message, Throwable t, Object param);
> trace(Object message, Throwable t, Object[] params);
> All levels would need analogous methods.
> The implementation of these and existing methods should change slightly,
> to first attempt to retrieve the log messages from a resource bundle (if
> a bundle exists). If the key cannot be found, return Object.toString(),
> otherwise use ResourceBundle.getString() to create the displayed
> message.
> While this adds numerous (24!) methods to the Log interface, the
> development effort required to implement is limited due to the
> intelligent structure of the Log impls already written, and having this
> full set of methods may be the easiest for commons-logging users.
> There is a slight performance penalty, due to having to add a check to
> see if a resource bundle is set. Perhaps there is an alternate
> implementation that can avoid this penalty altogether such as having the
> LogFactory return a different implementation of the Log depending on if
> a resource bundle is needed?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message