incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars Kühne <>
Subject Re: coding standard and logging
Date Mon, 10 Apr 2006 21:18:38 GMT
... and I thought logging was one of the easier problems when building 
an ORB :-)

Daniel Kulp wrote:

>j.u.l supports passing objects in as message parameters. 
>public void log(Level level,
>                String msg,
>                Object param1)
>public void log(Level level,
>                String msg,
>                Object[] params)
>The msg string can be a property in the ResourceBundle associated with the 
>logger instance.

Yeah, the ResourceBundle (including it's locale) is associated with the 
logger and not the handler. In other words, it's impossible to use one 
logger and have multiple handlers, each with it's own output language. 
It is even impossible to control the output language at all, because 
j.u.l.Logger.findResourceBundle() will always use the default locale.

Again, I don't really need internationalized logging in low-level 
infrastructure code like ORBs (or servlet engines or O/R mappers or 
thelike). I just want to make sure that I can read the logfile if I have 
to, so it better be english no matter where my software is running.

And even if all of this i18n stuff was possible with j.u.l, by 
hardcoding j.u.l into the ORB you'd leave all log4j users in the cold, 

I still prefer the IoC approach because it's integration friendly, 
doesn't suffer from classloader problems and can be made as flexible and 
sophisticated as we like.

Until now I have only seen a message from Edell stating that "Having to 
pass Loggers around is not a good idea." but no explanation why. It's a 
bit surprising, because the current code has been donated by you Iona 
guys and actually uses the IoC approach. All I would do is change the 
Logger interface a little.


>   The handlers in j.u.l just get a LogRecord object 
>which also has access to the parameters, ResourceBundle, etc....
>On Monday 10 April 2006 06:44, Lars Kühne wrote:
>>Yeah, that would be nice, but "displaying" would require implementing a
>>dedicated viewer application, whereas now we can simply use any
>>standard tool, like vi, tail -f, grep, etc.
>>Actually, we do have some machinery to implement logging in multiple
>>languages at the same time. We end up with multiple logfiles, one in
>>english for our support team, and one in the local language. However,
>>that code is specific to log4j because only log4j allows passing in any
>>Object as the "message" parameter.
>>We log Localizable objects that carry resource bundle info, resource
>>key and params, and use a special log4j Layout that handles such objets
>>by calling getMsgForLocale().
>>interface Localizable {
>>  String getMsgForLocale(Locale locale);
>>The difference to the standard j.u.l approach is that localization is
>>done by the Layout and occurs at the latest possible time, just before
>>the message is written to the log file by the appender. This means that
>>the appropriate locale can be chosen individually for each appender.
>>Unfortunately, I don't see how this approach could be generalized to
>>support j.u.l as well :-(

View raw message