I believe the threading model is a big reason for moving to version 2. Please read the archives about threading/deadlock issues.
Jake Thorbjørn Ravn Andersen wrote: > Ralph Goers skrev den 03-08-2008 21:45: >> 1.2 is the only current version. 1.3 has been discontinued. The basic >> work to start 2.0 has been done. A branch has been created for the >> initial 2.0 work at >> https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/. >> Jira has been setup to capture all the work for 2.0 at >> https://issues.apache.org/jira/browse/LOG4J2. >> >> I expect to start doing stuff in the branch within the next few weeks. > I looked through the issues and there is as nothing that springs in my > eye as particularily warranting a version 2 (except that to change JVM > level a version number change is needed, and what benefit will changing > source code to use e.g. generics bring that warrants dropping 1.2, 1.3 > and 1.4 as supported platforms?). > TurboFilter functionality would be nice, but should be possible to build > in without dropping backwards compatability, so it could be added to > 1.2 instead. > > I can additionally think of these things that would be nice to have: > > * configuration "scopes" - e.g. a JBoss configuration file along with a > web application file mess each other up. It would be nice if they > could have seperate root loggers which did not step on each others > toes. This might also be able to solve the "log4j cannot use log4j to > log" issue. > > * A "log to console only" behaviour if no configuration is active, to > make the default behaviour the same as for the other logging frameworks. > > * Support of ZeroConf in the standard loggers (where appropriate), as > network sockets are the currently best way to do inter-JVM communication > which is necessary to use Chainsaw or an Eclipse plugin etc or to do > centralized logging. People who have not used OS X have not seen how > elegant "just works" can be done. The work done in chainsaw is just the > beginning. > > * Before any work is done to improve performance, care should be taken > to be able to compare "before and after" to see if performance actually > improved. > > > At this point in time I think it would be very beneficial to create a > specification of requirements to be able to discuss what work should be > done, and to determine when the next version is ready :) Otherwise it > might be hard to collaborate on getting there. > > Just my 2 cents... > > -- > > Thorbjørn Ravn Andersen "... plus... Tubular Bells!" > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
