... and I thought logging was one of the easier problems when building
an ORB :-)
Daniel Kulp wrote:
Umm.....
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,
right?
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.
Cheers,
Lars
The handlers in j.u.l just get a LogRecord object
which also has access to the parameters, ResourceBundle, etc....
Enjoy!
Dan
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 :-(
/Lars
