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
[EMAIL PROTECTED]
