At 06:11 PM 12/20/2004, Curt Arnold wrote:
The existing AbsoluteTimeDateFormat, ISO8601DateFormat, and DateTimeDateFormat contained buggy caching code and had been effectively abandoned since PatternLayout no longer created these classes, but created java.text.SimpleDateFormat objects. The proposed resolution was to reimplement those classes as wrappers of SimpleDateFormat.
yes, and imho it's quite a bright proposal too.
The flawed caching code in the unused DateFormat's, if properly implemented, could result in a noticable performance benefit. A new class, CachedDateFormat, was written that could wrap any DateFormat.
If the class is introduced, then PatternLayout should be modified to wrap the DateFormat that it constructs with CachedDateFormat. If CachedDateFormat proved to be unreliable, then it would be trivial to remove by changing a line or so in PatternLayout.
As invoked earlier, I think CachedDateFormat may fail for certain patterns at certain dates. If we can recognize the limited number of formats for which it fails (if it does) and sidestep those, then fine. Before going any further, do you agree that patterns causing CachedDateFormat to fail exist and that it's just not me making things up?
CachedDateFormat attempted to support multiple digit sets. However, I couldn't find any stock Java locales that used a digit set other than 0-9 in its date formats. I had expected that the Thai locale would use Thai digits, but I was wrong.
If I am not mistaken, the existing code in CachedDateFormat only localized the digit 0. Which may be enough in case the SimpleDateFormat intance and CachedDateFormat instance use the same Localization but if not, then the output will be inconsistent.
Date formatting was affected by the current locale and timezone of the thread and there was no mechanism to configure a timezone or locale to be used. The existing patches added configurable timezones and locales to the pattern layout which would modify the behavior of the date formats. Based on some of the previous discussions on the Jakarta Commons Dev list, I'd like to evaluate whether Appender is a better place for the locale to be specified.
What I'd like to do is:
Commit simplifications to the DateFormat's and add CachedDateFormat but simplified to only recognized arabic digit sets.
That would be good.
Review configurable locales and timezones and come back to the list with a specific recommendation. My current take is that appender is probably a more appropriate place to specify locale. However, that should be considered in a bigger scope where locale affects both the layout and rendering non-string messages. TimeZone is likely still appropriate to configure on the layout.
This raises a much wider question. Should a given customization be allowed at the logger repository level, logger level, appender level, at the layout level or at the pattern converter level? Getting the answer right provides tremendous added value. For example, the named logger hierarchy propagates 'level' values according the level inheritance rule. This in turn provides a very fast, yet meaningful filtering mechanism for categorizing logging statements. The fact that we got this question right is one of the main reasons behind log4j's success. Appender additivity is another example showing that getting the collaboration rules between components correctly makes a big difference.
I happen to think that the logger repository should/can be viewed as the central point influencing all the components attached to it. For example,
1) properties of the logger repository should/can be visible at all components levels.
2) new pattern conversion rules defined at the logger repository level should/can be shared by all the instances of PatternLayout attached to that logger repository.
3) a resource bundles attached to a logger repository should/can be shared by all *loggers* (hint hint), appenders and layouts.
4) The mapping URL (defined below) attached to a a logger repository should/can shared by all instances of %logger2 pattern converter.
In "should/can", the "should" part signifies my current inclination to think of the above as good design. The "can" part means that design is still open for debate.
What is the mapping URL? ------------------------
We routinely write o.a.l.r.RollingFileAppender instead of org.apache.log4j.rolling.RollingFileAppender. The first form is almost as precise and much shorter. Whenever I get the chance, I'd like to implement a pattern converter named %logger2 which instead of printing org.apache.log4j.rolling.RollingFileAppender will print o.a.l.r.RollingFileAppender. The shortened forms will be defined in a properties file defined by the user. (We will provide a default mapping.) The location of this mapping will be specified with a URL hence the term "mapping URL".
Coming back to the TimeZone question, we could imagine that a TimeZone could be set at the LoggerRepository level. This TImeZone would percolate down to all levels below. However, if needed it could be overridden at a lower level, e.g. the pattern converter level. Can the TimeZone influence multiple pattern converters of a PatternLayout? If that's not a plausible scenario, then it does not make sense to define a TimeZone at the Appender level nor at the PatternLayout level.
Providing too many or meaningless extension/customization points will confuse the user, make thins harder to manage for her, and makes the code harder to maintain for us. Getting the collaborations rules right makes all the difference in the world.
-- Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
