You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Boris Unckel <bo...@gmx.net> on 2006/04/20 22:05:33 UTC
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.3-alpha8 - Extending TimeBasedRollingPolicy
Posted by Curt Arnold <ca...@apache.org>.
On Apr 20, 2006, at 3:05 PM, Boris Unckel wrote:
> 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
>
That is the reason that new stuff is generally marked final. For a
more complete discussion see "Item 15: Design or document for
inheritance or prohibit it" in "Effective Java".
If there is a compelling reason that something should be open for
extension, then it is always possible to drop the final qualifier,
however it is impossible to put final on a class without
compatibility issues. The default behavior now is to tightly
constrain new code and loosen it up if and when compelling use cases
are presented.
Instead of copying code, your implementation of the interface could
delegate to an instance of TimeBasedRollingPolicy. For a discussion
on that, see "Item 14: Favor composition over inheritance".
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org