At 12:01 AM 12/21/2004, Curt Arnold wrote:
I'm going to have do some research before I can make a reasonable proposal.
Here is a use case that I think suggests that Layout or Appender is the right level: Send logging events to Ceki in fr-CH localized email messages with time in Central European Timezone and to Curt in en-US email messages with time in US Central time zone.
However, if you were using a SocketAppender instead and receiving in Chainsaw, there would not be a layout involved, however you would want to be able to control the locale used in the Object.toString() call used to render non-string messages. Timezone would not come into play until a layout was involved.
The Object to String conversion is done once and only once. The result is cached and subsequently shared by all appenders. While I can imagine having two emails (thus two layouts) having different timezones, I can't see the use case for outputting an event in German through one appender, Dutch in another and in English in a third.
Locale and timezone, like layout, are accommodations of the preferences of a particular audience being reached through the appender. Can you think of reasons that you would want to specify them at a higher level?
I have to admit that I actually have a hard time imagining any use for setting the TimeZone because:
1) if events are to be viewed locally, they will be formatted using the system default TimeZone which is usually the same as the desired TimeZone.
2) if events need to be viewed remotely, they are transmitted in a TZ-neutral form over the wire. The recipient can output the event in its local TimeZone.
The only remaining case is then the user wanting to output the event in a TZ other than that of the her system (default) TZ. However, in that case we could ask the user to specify a non default TZ for each of her PatternLayouts that require it. No need to specify it at the LoggerRepository level.
Implementing appender level locale rendering would likely involve creating threads to do rendering on non-default locales in some instances and would likely have some performance hit, but shouldn't significantly performance when not specified. However, it is going to take some experimentation to see where it can be effectively performed.
The conjunction of the words "level" and "locale" made me think of the case where the level string was output in the user's locale. So, English speaking users would see TRACE, DEBUG, INFO, WARN, ERROR, EMERG a French speaker would see TRACE, BOGUE, INFO, AVERTISSEMENT, ERREUR, URGENCE a Turkish speaker would see IZ, DEBUG, BILGI, DIKKAT, YANLIS, IMDAT.
Many developers would want to see the level strings translated to their own language while many others would prefer the English terms. However, their preference would probably be the same for all appenders. So, setting the Locale at the LoggerRepository level makes sense. The user could later override the output language of the level strings (i.e. the locale) for a specific layout instance (most probably within the %level pattern word).
If the Locale could be set at the LoggerRepository level, in order to obtain localized level strings, the user could simply write:
<configuration xmlns="http://...>
<!-- new action: --> <localized-level-strings/>
<!-- the rest remains same as before --> <appender name="A1"> ... <appender> <appender name="A2"> ... <appender> <root> <appender-ref ref="A1"> .... </root> <configration>
Thanks for bearing with me this far.
-- Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
