Cool.  I knew it wasn't personal, and the SMTPAppender wasn't the point.
(I'll send the patch under a seperate header.)  I just wanted to make sure
that everyone writing code for the project remembers how important it is to
make the code extensible via subclassing.  (By not using package
members/methods, providing accessor methods, using accessors within the code
instead of referencing the member directly [which also tends to make faster
code since it can then get the variable from the stack instead of the heap],
etc.)  Especially on a project like this that's used by thousands of
programmers, the ease with which they can extend -- rather than rewrite --
that functionality is extremely important.

That said, of course, log4j is extremely flexible and well written.  It's
just that, being so, problems like the above are all the more glaring.

-Jim Moore


-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 19, 2001 5:00 PM
To: LOG4J Developers Mailing List
Subject: RE: Log4J beyond 1.1, thunderdome!



Hello Jim,

If you feel that your contribution is being ignored then nag. If that
doesn't work, then nag some more. I would dare say that participants in the
log4j project are mere mortals. That applies to other open source projects
in Jakarta, XML, PHP and httpd. We make mistakes, overlook excellent
contributions, write buggy code, under document etc etc.

However, it is never personal. You are kindly requested to resubmit your
SMTPAppender patch. I apologize for the inconvenience. Regards, Ceki

At 12:58 19.05.2001 -0400, you wrote:
>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]

--
Ceki Gülcü


---------------------------------------------------------------------
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]

Reply via email to