incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: coding standard and logging
Date Mon, 10 Apr 2006 11:41:36 GMT


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.   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
>
> Dain Sundstrom wrote:
> > In these cases wouldn't you want to log the raw data (message id and
> > parameters) and then localize when displaying?  That way anyone could
> > view the logs.
> >
> > -dain
> >
> > On Apr 9, 2006, at 1:33 PM, Lars Kühne wrote:
> >> Hi Edell,
> >>
> >> Nolan, Edell wrote:
> >>> [...] As regards getting the wrong language - this won't happen
> >>> because this is actually based on the locale - The Logic ensures 
> >>> it picks the most specific one to the more generic one.
> >>> So in the case if you are in germany you will never get thai etc.
> >>
> >> you got me wrong: We are in developing in germany, our customers 
> >> are running our software in Thailand (or wherever). Hence we will 
> >> get error messages that are not helpful at all for our engineers.
> >>
> >>> Note from the Class ResourceBundle API:
> >>>
> >>> Resource bundles contain locale-specific objects. When your 
> >>> program needs a locale-specific resource, a String for example, 
> >>> your program can load it from the resource bundle that is 
> >>> appropriate for the current user's locale.
> >>
> >> That is the point. For GUIs the current user's locale ist exactly
> >> what you want. For logfiles, it's exactly *not* what you want,
> >> unless your developer/support team speaks each customer's language.
> >> For us (and I assume most globally active software vendors?) this 
> >> is not the case.
> >>
> >> Regards,
> >> Lars

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727  C: 508-380-7194
daniel.kulp@iona.com

Mime
View raw message