On Dec 21, 2005, at 8:21 PM, Mark Womack wrote:
I prioritized the task list from the previous thread. Not all of
these are dependent on each other, but I beleive that we should look
at completing the first 2 before seriously tackling anything else.
The last 4 could happen in any order and most likely in parallel.
Documentation will get setup and then be ongoing.
- Restore binary compatibility, restore as much source
compatibility as needed
I've started on parts of it. Obviously would be good to have more
hands if we can coordinate/partition the work. May make a stab at
switching the Level/Priority stuff back around over the next two days.
Binary compatibility will require resurrecting the 1.2
RollingFileAppender and DailyRollingFileAppender, the facades over
the o.a.l.rolling.RollingFileAppender would not be compatibility with
any user extensions.
Anybody want to explain what QuietWriter's were and why the
disappeared in the 1.3 branch?
- Locking/threading/synchronization issues
I think it will be difficult or impossible to safely address the
"locks when trying to log during a toString() call" without
potentially breaking somebody else. It is an undesirable established
limitation of log4j, but it has existed there for a long time.
Probably should be better documented that any object passed as a log
message cannot call log4j as part of its toString call. The problem
should go away with a finer-grained locking in 2.0.
- Packaging changes
An combined jar file that is a drop in for log4j-1.2.x.jar would be a
nice addition. The auxiliary jars (log4j-db.jar, etc) should have
the version in them.
- Build changes (Maven2, etc)
- Review internal message logging mechanism, too verbose right now
That may need to be addressed as part of the restore binary
compatibility.
- Finalize slf4j support: direct or adapter?
- Documentation - update, get community involved
- JoranConfigurator review
- Plugin/PluginRegistery review and implementation
- Watchdog review and implementation
- Expression language review
I still like the idea of monthly releases. What's there is there when
we build. As Jess voiced, I think the goal of the end-of-January
release should at least be the binary compatibility, maybe even the
sync issue if we can manage it.
Overall goal for the release should be middle of the 2006. This
probably means the first beta version sometime in the April/May
timeframe. I've been very wrong about release timeframes for
everything from 1.2 releases to the last estimate for 1.3, so I am
very open to other suggestions and comments here. The goal is to give
the community time to digest the changes while also moving forward.
Comments? Other tasks? Different prioritization?
Full API review needs to be completed before calling it a beta.
Systematic code review of changes between 1.2.x and 1.3 would also be
good.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
