> 3) The internals of log4j are not yet stable. In log4j 1.3, log4j will use > itself for its own logging, which means that there must a clear separation > between log4j's internal logging space and the rest. We do not have that > yet. This will be solved by log4j domains. Domains do not require much > code. A better description of the problem will follow once 1 and 2 are > completed. >
I'm looking forward to checking out domains, they sound very cool.
> 4) Log4j needs to deliver management events to support various listeners > and management operations.
I was actually planning on adding PropertyChangeListener stuff to the Plugin side of things today. On the LogManager side, what is our plan here, perhaps I can help.
The idea is to have listeners attach to the hierarchy (or logger repository). Each time a logger changes its level, or appenders are attached/detached from it tells its hierarchy to notify the listeners. (Listeners are per hierarchy not per logger).
Events of interests are:
- hierarchy threshold change
- logger creation,
- logger change (level, appender)
- appender change (Appenders tell the hierarchy to notify listeners. Thus, appender have to have know the hierarchy where they belong. to It is up to the appender to decide when to tell the hierarchy to notify listeners.)
> 5) Log4j should be manageable by JMX.
This will be fun, JMX is amazingly useful.
Point 4 is a prerequisite for 5.
> What else do you have in mind?
Nothing you haven't mentioned, just the timeline. So 30 September is the goal?
It's not a hard deadline. There is really much to be done.
cheers,
Paul
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
