Re: [SUBMIT] Timezone support for date elements of pattern layout

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

Mark, Mike,

I intend to release log4j 1.2.6 this week. After that I will merge the
1.2 branch with the main trunk. This is the first task to tackle
before merging Mike's changes. The 1.2-1.3 merge is likely to be time
consuming.

I believe that from the various options that Mike added only the
decimal separator and timezone should be retained.

Regarding PatternLayout enhacements, the %conversionWord{key=value,
key=value, ... } format is preferable.

The idea of searching converters by reflection is a good
idea. Regarding case sensitivity, according to the Java Beans
conventions the first letter of an option is case
insensitive while other letters are case-sensitive. For example,
helloWorld and HelloWorld are deemed equivalent while HElloWorld and
HelloWorld are not. We can follow the same convention while searching
for pattern converters.

One possible idea is for the user to give directions about the
packages to search for. For example, if the users tells use to the
search the "com.foo" package and the convention world is "%hello", we
can attempt to locate the "com.foo.HelloPatternConverter" class. We
can assume that the list of packages to search for always includes the
"org.apache.log4j.xyz" package where xyz is yet to be determined.

ps: 1.2.6 will bring enhancements to the JMSAppender and bug fixes. I
also added a getLoggerName method to LoggingEvent so that directly
accessing the categoryName is no longer needed.

At 06:44 30.07.2002 -0400, you wrote:
>mwomack@apache.org wrote:
>>Wow.  Ceki, I am surprised you have not commented on this yet.
>
>Mark,
>
>Be kind.  Maybe Ceki also has a real life that has kept him away from this 
>list.  I had a little extra time on my hands this past weekend, and I had 
>been thinking about this idea since the first time Ceki had pointed me to 
>his enhancements document.  So I just put my current thoughts on paper.
>
>>Maybe I
>>missed it being so busy at work lately.  But if Mike implements to the
>>supplied javadoc, it looks like it would implement most of the PatternLayout
>>proposal (http://qos.ch/specs/PatternLayout.html) except for maybe
>>dynamically specifiying new conversion words.
>
>That's an implementation detail.  I intend to use reflection to find the 
>relevant o.a.l.helpers.PatternConverter that is then added to the linked 
>list.  If I do this right, it should be possible to create new 
>PatternConverter subclasses for new Pattern Ids, and to find these new 
>PatternConverters in the Classpath.  I haven't yet figured out the best 
>way to find new PatternConverter subclasses (since they won't be in the 
>o.a.l.helpers package), so any suggestions would be appreciated.
>
>>I would choose to have
>>lowercase conversion words instead of mixed case.
>
>That's fine.  My idea is to find instantiate subclasses of 
>PatternConverter using Reflection.  I expect that subclasses of 
>PatternConverter would be PatternidPatternConverter, so I will up shift 
>the first character of the Pattern Id and down shift all the other 
>characters to build the class name.  Thus, Pattern Ids will not be case 
>sensitive.  I think that subparameters will also be case insensitive.
>
>>I would also choose the
>>single % with {} for grouping specifiers as in Ceki's proposal (instead of
>>matching % characters), but the core appears to be there.
>
>I chose beginning and ending % characters to simplify identifying the 
>conversion words.  As for using {} instead of @ for subparameters, I'm 
>willing to do that.  I have to admit, I created the Javadoc without 
>reviewing Ceki's document.
>
>>But frankly, I think that doing this is not required to accept Mike's first
>>round of changes he has submitted.
>
>This would be nice.  I've imported the current 1.3 code to my machine, and 
>I have looked at how some of the proposed changes might affect other 
>classes.  For example, I think that my ideas would require changes to 
>o.a.l.helpers.FormattingInfo.  Since this class is only usable within its 
>package (even though the class itself is public) I don't expect changes to 
>it to break other code.  However, I don't know if there are any 
>implementations of Log4J with new classes added to the the Log4J 
>packages.  I don't think I've seen anything in the documentation 
>discouraging creating classes in packages already found in the Log4J 
>distribution.
>
>Is this a situation about which I should be concerned?
>
>--
>Cheers,
>Mike McAngus
>mam@infinet.com
>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>