incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: coding standard and logging
Date Thu, 06 Apr 2006 23:30:55 GMT

On Thursday 06 April 2006 18:12, Lars K├╝hne wrote:
> Daniel Kulp wrote:
> >Neither of those two support i18n capabilities in the logger.   Thus,
> > you would need to i18n the log messages ahead of time.     One of the
> > nice things about JDK logging is that they can be created with the
> > resource bundles that contain the i18n messages.
> I'm not sure this is really desirable. I need to be able to at least
> control the locale of the generated output. I don't see how j.u.l
> allows that, it seems to always use the default locale.
> I work for an independent software vendor, and our applications are
> installed globally. To support our products we need their logfiles in a
> language that our developers understand (i.e. english or german).
> Receiving logfiles that contain error messages in Czech, Thai,
> Norwegian, etc. is not a viable option for us.

The policy we have for Celtix (although not followed as well as it should 
be) is that stuff logged with SEVERE or WARNING should always be 
localized.   The basic reason is that this is stuff that an admin of the 
application probably needs to know while trying to figure out what went 
wrong, why the application didn't start, servlet didn't deploy, etc....   
Example:  FileNotFound type things or "Cannot connect to host" things 
that the admin shouldn't have to contact us to fix.    Stuff in INFO and 
lower are usually only useful for us or someone VERY familiar with the 
code.   Thus, we don't normally localize those.   

The good thing is the j.u.l stuff supports that and whatever you guys 
choose should as well.   It's important that users have the ability to 
localize the errors so their admins can diagnose stuff without having to 
contact us.   Anyway, Celtix ONLY uses j.u.l based logging.   That said, 
the ability to have a "root" logger based on the current Bus ID like Lars 
described definitely would be useful and makes sense, although that could 
easily be done with the j.u.l based logging as well.  (except our 
checkstyle rules would complain, but that's a different issue)

J. Daniel Kulp
Principal Engineer
P: 781-902-8727  C: 508-380-7194

View raw message