We can write it so that the repository-set properties are either available via getMDC or not - I don't care either way, since I could use getProperties on loggingevent to retrieve the MDC + repo properties.
slf4j has gained some traction out there - it seems as though our direction (providing a way to send & receive between log4j & java.util.logging) is also a valid way to help people avoid commons-logging. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -----Original Message----- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Thu 6/21/2007 3:56 AM To: Log4J Developers List Subject: Re: apache-log4j-component-1.0 rc2 On 21/06/2007, at 4:18 PM, Scott Deboy wrote: > I'd still like us to consider finishing the property support > included in LoggerRepositoryEx (mostly requiring new functionality > being added to LoggingEvent). It would make finishing up the > backporting of the appenders & receivers essentially complete. > Will these new functionality still retain binary backward compatibility? > Also, I'm not sure of the state of our support for slf4j via > ULogger - are we planning on removing that or tracking slf4j? > Gosh, I hadn't even thought about this. I don't even remember the concept of ULogger. Maybe slf4j is the way to go, we could use maven profiles to produce two seperate versions of log4j? Paul --------------------------------------------------------------------- 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]