Hi Boris, Thanks for taking the time to reply. I find it 'strange' that we are using a language that is all about extending and re-using and here we are espousing locking down and non-reuse. We might as well be writing log4j in C for all the extensibility we have. Regardless, I gave up on the approach I proposed earlier.
I am not sure I agree with this position but I am sure it has all been thrashed out before I joined this list. ...Lyall -----Original Message----- From: Boris Unckel [mailto:[EMAIL PROTECTED] Sent: Friday, 21 April 2006 5:36 AM To: Log4J Developers List Subject: Re: 1.3-alpha8 - Extending TimeBasedRollingPolicy Hello Lyall, Pearce, Lyall wrote: > I am unsure if this is more a user or developer question, I will lean > towards developer unless told otherwise. > > > log4j1.3-alpha8 has a nice class TimeBasedRollingPolicy > (http://logging.apache.org/log4j/docs/api-1.3/org/apache/log4j/rolling > /T > imeBasedRollingPolicy.html) > > The Primary question: Why are the classes marked final? Why can't I > extend a log4j class? I am not a log4j developer. I have seen the discussions about compatibility on this list for the development of log4j 1.3 and the enormous efforts spend on compatibility. It is very hard to change the internal implementation of an class if lots of people are extending it and relying on a specific behaviour. If you want to have your homegrown XYZPolicy: Copy the code, implement the interface and use it. If log4j developers want to change something, they just have to care that the interface is not broken, but they can change the other class without braking anyones code. Regards Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
