I agree with everything on your 1.3 task list. I've always felt that we need to take pains to ensure compatibility at the binary level and with public apis (domconfigurator, etc.). Preventing synchronization-related issues is critical as well.
There are other issues we need to resolve as well, including: - do we really want one jar for each external dependency (oro, xml, etc.) - there are two expression language implementations I think our users would appreciate more information about our planned releases (timelines/features). We should define a prioritized feature list. We could then take one of two routes: Advertise the approximate delivery dates of releases and the features planned for inclusion in each release, or (my preference): deliver releases on a fixed interval, and what we have time to include is included. The JXTA project seems to work this way. Scott -----Original Message----- From: Mark Womack [mailto:[EMAIL PROTECTED] Sent: Mon 12/19/2005 9:12 PM To: Log4J Developers List Subject: 1.3 Tasks (and beyond) As Curt has mentioned, we got together for a little while to talk about 1.3 stuff. I have included the list of tasks we came up between ourselves. I'm sure it is not complete, but gives an idea of some scope. Please feel free to comment and add more as you see it. The one thing that really struck me at ApacheCon, and has been reflected here and on the users list, is that big changes in the API and binary compatibility is going to really mess people up. If there are big changes, it is going to really affect the adoption of log4j 1.3, and I think we need to seriously ask ourselves if we want the current level of change that is reflected in the current source. I'm all for moving forward and adding features, but I think we need to do it in a context of maintaining a high level compatibility. Curt has done work to generate a binary compatibility report, and Paul was able to set up a jDiff report task. I think that between the 2 of them we should review and start the work of reverting back to the 1.2 api as much as possible, having fewer breaking changes. Adding new features like Plugins, JoranConfigurator, Receivers, Watchdogs is still doable. And get the needed feedback from the community going forward. For the big breaking changes, I think we should look to log4j 2.0. We can really look to that version to do some fundamental work from the ground up, fix the things that really bother us, target features in the current JDK's (1.4, 5.0), etc. In that version, we should expect to break things. We can really look at things fresh and do new things. I don't know how much the core workings will really change, but the stuff built around them could change. Anyway, it is just thinking at this point. Breaking lots of things in 1.3 and then breaking them all over again in 2.0 is asking too much of the user base, IMO. But I'm not a project manager/leader here. What do you guys think? Here is the list of stuff I had from ApacheCon (below). Please feel free to comment/add. It needs to be translated to a set up 1.3 bugs at some point, but we can discuss in email for now. -Mark log4j 1.3 tasks (this is just what Curt and I came up with between us) - locking/threading issue - prerender the message before the lock? - restore binary compatibility, restore as much source compatibility as needed (this is a really big area which needs an email on its own, but a few items...) - switch the Priority/Level change - binary compatibility of LoggingEvent between 1.2 and 1.3 (drop sequence number?) - 1.3 should pass 1.2 unit tests? - restore DOMConfigurator and a bunch of other classes that have been removed. ...and much more... - JoranConfigurator/DOMConfigurator review - silent failures right now, add methods to get configuration exceptions - support namespaces - support different rule sets to be defined (basically reuse JoranConfigurator for different formats?) - finalize slf4j support: direct or adapter? - Review internal message logging mechanism, too verbose right now - Plugin/PluginRegistery review and implementation - Watchdog review and implementation - Documentation - update, get community involved - build changes - log4j-all jar - separate binary and source distributions - put external dependencies into build tasks, or Maven2 - gbuild (build system for Geronimo) support for official builds and testing log4j 2.0 thoughts (these are just thoughts now, don't freak out) Will break extensions source wise and break binary compatibility. - fundamental redesign - reorganize the classes/packages (interfaces vs implementations, group under packages), get rid of deprecated classes - configuration vs runtime (immutable) objects - finer grained locking for synchronization - Serialized version of LoggingEvent supportable across log4j 2.X versions and other logging services projects - new package name (log4j2?) - Implement to target more recent JDK (at least 1.4.X, use 1.5 annotations, etc?) - Cleaner design of what is a core, public interface and implementations - Use modern best practice designs from the core on up - Focus on core classes with "required" entities - Design entities for better encapsulation of members and methods - Precisely define lifecycle events and callbacks - Precisely define extension points --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
