logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: TimeZone and locale for PatternLayout Was: [RESULT][VOTE]
Date Tue, 21 Dec 2004 19:15:39 GMT
At 07:01 PM 12/21/2004, Curt Arnold wrote:

>Allowing TZ to be specified at the repository level would add an 
>interaction between layout and repository that I don't believe currently 
>exists and I don't see it adds much additional value.

Excellent point. Now note that as explained in [1], there are several
cases where it makes sense to let most, if not all, log4j components
know about the LoggerRepository they are attached to.

Use case 1: Loggers retrieve resource bundles from the LR. (Loggers
already know their LR.) BTW, this assumes that only a single location
is performed for all appenders. If localization is performed per
appender, then it makes sense for appender to retrieve locale specific
resource bundles from the LR, implying that appenders know about their

Use case 2: PatternLayout retrieves new conversion words from its
LR. (In 1.3, PatternLayout can learn new conversion words on the fly.)
Mrs. Piggy would set up new conversion words in a XML config
file. These new rules are placed within the LR and all PattternLayout
instances inherit those new words from the LR.

Use case 3: the %logger2 pattern converter will shorten package or
class names according to a mapping specified by the user. Again,
Mrs. Piggy would specify the mapping in a config file. This mapping
would be shared by all instances of %logger2.

Use case 4: Properties (key=value pairs) can be set at the LR
level. It kinda makes sense to share these values across components.

[1] http://marc.theaimsgroup.com/?l=log4j-dev&m=110357800507837&w=2

>I think that we should pick one place to add it and the gather feedback to 
>see if we picked the wrong place or need to add additional specification 

Expecting the end-user to understand all possibilities and return with
valuable suggestions does not always  work and in general takes a very
long  time. Actually,  expecting experts  to come  back  with valuable
input  does not  always work  either.  The  best approach  is thinking
about the problem as hard as  you can, covering as many aspects as you
can,  and  come  back  with  a  proposal,  or  even  better,  with  an
implementation.  However, you seem to know this better than I do.

Ceki Gülcü

   The complete log4j manual: http://qos.ch/log4j/

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message