Multiple options in pattern layouts (aka TimeZone for Date patterns)

[Curt Arnold <ca...@houston.rr.com>]

I've got a fairly clean modification to PatternParser that enables 
specification of TimeZone for the %d pattern.  In the mod (shortly to 
be committed if no one screams), the PatternParser looks for an 
unlimited number of curly braced parameters after a format 
specification.  Every PatternConverter except DateFormat ignores all 
but the first.  DateFormat interprets the first as the format pattern 
and the second as the TimeZone id.  For instance, the following format 
would print out the time as both UTC and local.

%d{ISO8601}{GMT}Z %d{yyyy-MM-dd HH:mm:ss z} %c - %m%n

Only patterns where you intended a literal "{" to immediately follow an 
option would be changed by this mod.  For example, before the mod that 
format might result in "2004-12-22 13:48:52,000{GMT}Z ....".  If you 
wanted something like that, you could just add a space between the 
close } and the next {.


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

Re: Multiple options in pattern layouts (aka TimeZone for Date patterns)

[Ceki Gülcü <ce...@qos.ch>]

Curt,

Excellent initiative.

When PatternParser sees multiple the curly braces, how does it now which 
curly brace corresponds to which option to be handed to the 
PatternConverter instance? Do PattterConverters now have multiple setOption 
methods, e.g. setOption1, setOption2, ..., setOptionN. I'm only 
speculating. Looking at the code is probably the easiest way to understand.

Since you mentioned it, one could easily check whether the curly braces are 
escaped, as in "%x\{%t\} - %m%n". We have never worried about escaping the 
curly braces and no one has never asked for it... So dropping this issue is 
perfectly fine with me.

Have you given the %d{"option1", "option2"} form any consideration?  Just 
making sure that you are aware that it exists as a possibility...

Since we are discussions the subject, a more intelligent parser would 
define a grammar and break the pattern into expressions and proceed by 
delegation. The current code which keeps state within a single block only 
works for very simple grammars, those excluding recursive expressions.

Consider the following pattern

%-50(%d [%t] %5p %logger2) - %m%n

It left aligns the pattern "%d [%t] %5p %logger2" as a group. You can't 
possibly do that with the current code.

I'd be happy to discuss this further if there is interest.


At 08:50 PM 12/22/2004, Curt Arnold wrote:
>I've got a fairly clean modification to PatternParser that enables 
>specification of TimeZone for the %d pattern.  In the mod (shortly to be 
>committed if no one screams), the PatternParser looks for an unlimited 
>number of curly braced parameters after a format specification.  Every 
>PatternConverter except DateFormat ignores all but the first.  DateFormat 
>interprets the first as the format pattern and the second as the TimeZone 
>id.  For instance, the following format would print out the time as both 
>UTC and local.
>
>%d{ISO8601}{GMT}Z %d{yyyy-MM-dd HH:mm:ss z} %c - %m%n
>
>Only patterns where you intended a literal "{" to immediately follow an 
>option would be changed by this mod.  For example, before the mod that 
>format might result in "2004-12-22 13:48:52,000{GMT}Z ....".  If you 
>wanted something like that, you could just add a space between the close } 
>and the next {.

-- 
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