Hello Curt,
At first I had trouble understanding some of the constructions in CachedDateFormat but I am starting to get the hang of it. I particularly like the idea of being able to dynamically detect the placement of the millisecond field and adapt the cache accordingly. It's pretty good stuff.
Previously you mentioned that using CachedDateFormat to wrap the SimpleDateFormat created in DatePatternConverter did drop times from about 29 ms to 22 ms. What do these numbers represent? What do they measure *exactly*?
Looking at CachedDateFormat I also noticed that it attempts to handle the digit zero in a locale dependent manner. However, the code of CachedDateFormat which you supplied with bug #32064 [0] does not seem to be able deal with a user specified locale, that is, a locale different than the default locale.
I've also noticed that you modified PatternLayout to set the timezone
and locale for all of the converters each time something needs to be
formatted which is obviously a total overkill. (I guess you were just
testing the code.) As I suggested earlier, I think we can get away by
just allowing the user to set the timezone and locale as an option
within the %d{} conversion word, for example %d{yyyy-MM-dd
HH:mm:ss,SSS z, Japan/Tokyo, jp_JP}. There is no need to add timezone
and locale options to PatternConverter.Locales other than those using the latin alphabet make it hard (at least for me) to test the output. I was not able to test the output for any such locale, e.g. Japanese, Chinese, etc... Are you able to set your machine to use these languages?
Did I mention that your contribution is quite impressive? Well done.
[0] http://issues.apache.org/bugzilla/show_bug.cgi?id=32064
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/eclm/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
