On Feb 18, 2010, at 9:03 AM, Christian Grobmeier wrote: > Hi, > > just looked into it - first glimpse showed me version 1.2.15 on > http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2/download.html > Is this ok and changed while go live? > > On: > http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2/roadmap.html > It sounds a bit strange when it comes to: > "Any major new features for log4j 1.2 are likely to be developed as > companion products for log4j 1.2." > What does it actually mean? >
The idea at the time was that code that required JDK 1.4 or was less mature could live in the extras companion where it could be released more frequently. Good intentions, but didn't go as planned. I think the companions are appropriate for whole new capabilities, like receivers, or things add dependencies. However, we had the recent thread where someone needed to control the timezone in a date format and was aware of EnhancedPatternLayout, but did not want to add an extra jar. Parameterized logging is also a frequent request and while LogSF and LogMF may not be perfect, they are useful and can be improved. It is generally a bad thing to have multiple sources for a class, since you can get unexpected behavior with instanceof and casting. LogMF and LogSF are singleton classes, (o instanceof LogSF) is always going to return false, so I can't see a scenario where it would cause a problem. With EnhancedPatternLayout, you could contrive a problem, but it seems it seems vanishingly small to occur in the field. I thinking it is time to include LogSF, LogMF and EnhancedPatternLayout in log4j.jar. I did log an issue to add entering, exit and throwing methods to parallel the equivalent in java.util.logging. I was planning on doing that when working up an extras release to follow up on a 1.2.16 release, but that timeline doesn't work now. If you or anyone else wants to take a shot in the very near future, please look at http://issues.apache.org/bugzilla/show_bug.cgi?id=43277 and give a shout out. There was also a benchmark reported that showed an unexpected performance difference between LogMF and corresponding SLF4J calls in an old thread, but there was not an analysis to determine the source of the disparity. I filed bug 48778 for the issue. Again, this would be a helpful bug for someone to take on if they can do so quickly. Any thoughts? I'm planning on adding the necessary links this weekend and look at cutting another RC. If the fixes for those issues are in progress, we can cut another RC after they have been integrated. > On: > http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2/manual.html > http://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2/publications.html > there are character encoding problems > Maybe another Maven plug-in needs an encoding configuration. > I would think the benchmark can stay in as long as we have not a better one > > So far from me :-) Thanks for the work! > Christian > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
