Hi Ceki, thanks for pointing me to logback. But there are several reasons I would like to keep Log4J alive.
1) logback is distributed as LGPL, not Apache License. Both are compatible, but I prefer ASL. 2) logback is driven by a company and not an ASF project, which I prefer for several reasons 3) so much users are still using Log4J, including lots of Apache projects 4) old log4j and logback api feels a bit complex to me. I think both could be more simple That being said, logback is not an option for me at the moment nor was it necessary to use any of the new features it provides (speaking only of my own projects of course). This is why I would like to see a continuation on the log4j work. Best regards, Christian On Fri, Dec 11, 2009 at 11:02 AM, Ceki Gülcü <[email protected]> wrote: > Hi Christian, > > Have a look at logback. It is the continuation of the log4j 1.3 > effort, with 4 years of additional work. > > -- > Ceki > > Christian Grobmeier wrote: >> >> originally sent to the wrong list, sorry for the crosspost :-) >> >> >> ---------- Forwarded message ---------- >> From: Christian Grobmeier <[email protected]> >> Date: Thu, Dec 10, 2009 at 2:02 AM >> Subject: Future development of Log4J? >> To: Log4PHP Dev <[email protected]> >> >> >> Hi all, >> >> I looked at the svn of Log4J and saw that there is no activity on the >> 2.0 branch for 17 months. It seems that the 2.0 effort has been >> stopped 3 months after the failure of 1.3. On the 1.2 trunk Curt is >> still doing a great job with fixing bugs and caring about a new >> release. But it seems that he is rather alone with Scott. It also >> feels that Log4J is not having big step forwards, its more in a >> maintenance mode. And I am wondering why, because Log4J is still one >> of the most used frameworks for logging in most projects I know. >> >> However, I also looked into the code. With my experience I took with >> me with developing Log4PHP (which was quite near to the architecture >> of Log4J) I spotted out the project. I feel that Log4J needs much >> bigger steps now. It looks like outdated syntax which has been written >> for old versions of the JDK, very complex design (lots of extensions, >> deprecations and so on) and a very weird code format. I think there >> can be done much more as JDKs have progressed. >> >> Since there is less activity at all, I would like to know about your >> thoughts on the future development. I saw no posts at this topic at >> all. However, I strongly believe that with cleaning up Log4J lots >> could be won. I don't want to to step on anybodys tooth, but I think >> the project needs to refactor it's stuff, not caring about backwards >> compatiblity. Clean up the old deprecations and everything which was >> necessary to keep performance on old JDKs, but no longer. >> >> I am thinking on renaming packages to better names. Not longer "or" >> but maybe "renderers". Then there are much different classes stored in >> the same directory, which makes everything hard to understand. Please >> have a look in the log4php package structure to see what I mean. On >> first glance, I don't see why Category.java is necesary any longer. In >> a local version I have done these two steps and it looks so much >> better so far :-) >> Similar approach can help with removing classes like PropertyGetter.java. >> >> After that kind of clean up and refactoring, it should be quite easy >> to attract new developers and have new features on board. >> >> Again, I didn't want to step on anybody tooth, but I would like to see >> a new step in Log4J. Otherwise I am afraid this project is going more >> and more into maintenance mode, until it reaches the end of its >> lifecycle. And that would be too bad! >> >> Of course I am willing to contribute my changes or send it to any >> interested party as a zip file. But be warned, junit is not running >> smoothly atm :-) I am also willing to get my hands on. >> >> Cheers, >> Christian >> >> --------------------------------------------------------------------- >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
