On Dec 21, 2004, at 10:44 AM, Ceki Gülcü wrote:
At 12:01 AM 12/21/2004, Curt Arnold wrote:
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.
I think the multi-locale use case is reasonable, however it may be one that we reject as a requirement. I'd like to see how it plays out before rejecting it.
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.
I would think the most common use for an arbitrary timezone would be to specify that the time should be rendered as UTC. I do think that is still at the layout level (whether or not embedded in the pattern specification)
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.
I think working the locale issue through is going to take some experimentation. It would probably be best to take a shot at a regexp-based message localizing layout. Once we have that piece, then we can experiment on the localization of level names and ObjectRendering. However, I've going to have to say that I can't do that until after log4cxx 0.9.8 snapshot is stable.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
