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]
