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 <[EMAIL PROTECTED]> Socketware, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
