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>
Subject: [Logging] Internationalization enhancement proposal
From: Andrew McConnell <mcconnell@socketware.com>
To: commons-dev@jakarta.apache.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: Socketware, Inc.
Message-Id: <1045741254.2966.31.camel@mercury.headquarters.socketware.com>
Mime-Version: 1.0
Date: 20 Feb 2003 06:40:55 -0500

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?


-- 
Andrew McConnell <mcconnell@socketware.com>
Socketware, Inc.

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