> 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. > 5) Log4j should be manageable by JMX. This will be fun, JMX is amazingly useful. > What else do you have in mind? Nothing you haven't mentioned, just the timeline. So 30 September is the goal? cheers, Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
