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