You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ke...@barclayscapital.com on 2010/10/21 23:17:17 UTC
Extending extra RollingFileAppender
Hi,
I am looking to modify a small part of the write behavior for org.apache.log4j.rolling.RollingFileAppender from the extra companion jar. However, the class is declared as final. Is there any particular reason why this was done? Would removing the final keyword and extending the class my self be dangerous?
_______________________________________________
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________
RE: Extending extra RollingFileAppender
Posted by Ke...@barclayscapital.com.
The change is actually a modification to FileAppender's behavior which is why it can't really be implemented through the rolling/triggering policy classes. We essentially wanted to enable write buffering and force a flush at periodic time intervals. I had originally made this change by subclassing FileAppender but it was determined that we also needed log rolling functionality with a timed based policy.
I'm thinking I might just create a new class by copying and pasting RollingFileAppender and having it extend my subclassed FileAppender instead of the original one (or encapsulating if this ends up feeling too egregious). Thanks for your help.
-----Original Message-----
From: Curt Arnold [mailto:curt.arnld@gmail.com] On Behalf Of Curt Arnold
Sent: Thursday, October 21, 2010 9:16 PM
To: Log4J Users List
Subject: Re: Extending extra RollingFileAppender
The motivation for making the class final is that it was designed to be extended via the TriggeringPolicy and RollingPolicy classes. Joshua Bloch's design pattern of design for inheritance or prevent it.
If you can accomplish your goal by providing a custom TriggeringPolicy or RollingPolicy that would be the best approach. If you still run into a wall, you could describe how you would like to modify the class and providing a mechanism (either through the existing strategy classes or via a new one) to support that modification could be considered.
If not, then consider encapsulating the class (a bother since the Appender method has so many methods). If that isn't viable, then copy and pasting the appender source and changing the package, class name or both (while staying within the Apache Software License) is better than tweaked version of log4j with the final qualifier removed.
On Oct 21, 2010, at 4:17 PM, <Ke...@barclayscapital.com> <Ke...@barclayscapital.com> wrote:
> Hi,
>
> I am looking to modify a small part of the write behavior for org.apache.log4j.rolling.RollingFileAppender from the extra companion jar. However, the class is declared as final. Is there any particular reason why this was done? Would removing the final keyword and extending the class my self be dangerous?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
_______________________________________________
This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Extending extra RollingFileAppender
Posted by Curt Arnold <ca...@apache.org>.
The motivation for making the class final is that it was designed to be extended via the TriggeringPolicy and RollingPolicy classes. Joshua Bloch's design pattern of design for inheritance or prevent it.
If you can accomplish your goal by providing a custom TriggeringPolicy or RollingPolicy that would be the best approach. If you still run into a wall, you could describe how you would like to modify the class and providing a mechanism (either through the existing strategy classes or via a new one) to support that modification could be considered.
If not, then consider encapsulating the class (a bother since the Appender method has so many methods). If that isn't viable, then copy and pasting the appender source and changing the package, class name or both (while staying within the Apache Software License) is better than tweaked version of log4j with the final qualifier removed.
On Oct 21, 2010, at 4:17 PM, <Ke...@barclayscapital.com> <Ke...@barclayscapital.com> wrote:
> Hi,
>
> I am looking to modify a small part of the write behavior for org.apache.log4j.rolling.RollingFileAppender from the extra companion jar. However, the class is declared as final. Is there any particular reason why this was done? Would removing the final keyword and extending the class my self be dangerous?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org