My #1 request is that the code be written in a way that can be extended. A
great deal of the current code is written with critical sections using
package members/methods without any accessor methods to get to them. That
means that if you want to extend a class, you simply can't do so -- you must
completely rewrite it.
As a case in point, I wanted to SMTPAppender to provide "patterns" in the
subject so that when a email was sent it would automatically put information
about what caused the problem in the subject. (There are a few other
things, too, like having multiple SMTP hosts in case one's down.) However,
I couldn't extend SMTPAppender because all of the data is inaccessible to
subclasses, so I cut & pasted the code into my class and extended from
AppenderSkeleton instead. Ugh! To be a "good guy" I even went into the
original code for SMTPAppender, changed the members to be private with
protected accessor methods, and submitted the diff to this list (since I'm
not a committer) so other people wouldn't run into the same problem, but it
was never applied to the code. (No one ever said why.) Whatever. I've run
across this same problem in other places too, but the SMTPAppender really
disturbed me since it's an appender and therefore fairly likely for people
to want to extend with new functionality.
The point being, while log4j is currently great for "plugging in" new
features, it's not very easy (without resorting to cut&paste) to extend
current code.
-Jim Moore
-----Original Message-----
From: Mathias Bogaert [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 9:01 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Log4J beyond 1.1, thunderdome!
Hello,
To be able to plan the next releases of log4j, we would like to know what
new features/enhancements/changes/wishes you have in mind for log4j beyond
1.1.
Please voice them on the [EMAIL PROTECTED] mailing list.
Also:
- is the current documentation sufficient?
- a servlet to view the log (and sort, list, print), would this be usefull?
- a servlet to modify the log4j.properties, or is this overkill?
- should log4j support i18n? (dunno if it already correctly does)
TIA
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
