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 don't think you looked carefully enough. Fixing some of the way things
are currently implemented will probably break compatibility. For
example, getting rid of Category - which has been deprecated for years.
Creating a good implementation of LocationInfo requires Java 5 as that
is when Thread.getStackTrace() became available. nio didn't become
available until 1.4. Frankly, I have zero interest in working on a log4j
that doesn't have Java 5 as a minimum. Log4j is "good enough" for older
Java releases but real improvements need to be made.
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.
One way or another, JBoss and log4j need to play better together. I
created https://issues.apache.org/jira/browse/LOG4J2-18 just for that.
Feel free to update it with your thoughts.
* A "log to console only" behaviour if no configuration is active, to
make the default behaviour the same as for the other logging frameworks.
Agree.
* 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.
Yes - it is very important to have tests to continually measure that. I
already have one that I use.
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...
The point of the Jira issues was to do exactly that. I suggest that
instead of posting the ideas here where they will probably be forgotten
that you add them as Jira issues. Then go ahead and start figuring out
how to implement them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
