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 "Ralph Goers (JIRA)" <ji...@apache.org> on 2012/11/12 19:33:11 UTC
[jira] [Comment Edited] (LOG4J2-112) Why is FileRenameAction a
final class?
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495478#comment-13495478 ]
Ralph Goers edited comment on LOG4J2-112 at 11/12/12 6:31 PM:
--------------------------------------------------------------
"Why?" questions are usually not much fun to answer, but in this question the answer is easy. I borrowed from work others had done. In this case I believe RollingFileAppender started from https://svn.apache.org/repos/asf/logging/log4j/companions/extras/trunk/src/main/java/org/apache/log4j/rolling/. You will notice that FileRenameAction is final there. We have a lot of final classes in Log4j 2 but I'm not sure why this one needs to be. Most of the others all have private constructors and so aren't designed to be extended.
I see no reason not to change it. Can you submit a patch?
Also, if you believe your SharedFileRolloverStrategy could be used by others please feel free to submit that as a patch as well.
was (Author: ralph.goers@dslextreme.com):
"Why?" questions are usually not much fun to answer, but in this question the answer is easy. I borrowed from work others had done. In this case I believe RollingFileAppender started from https://svn.apache.org/repos/asf/logging/log4j/companions/extras/trunk/src/main/java/org/apache/log4j/rolling/. You will notice that FileRenameAction is final there. We have a lot of final classes in Log4j 2 but I'm not sure why this one needs to be. Most of the others all have private constructors and so aren't designed to be extended.
I see no reason not to change it. Can you submit a patch?
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Question
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> First some backstory:
> I have a special need to allow the use of a common/shared log file within a clustered environment. I have already taken other measures necessary to handle the simultaneous writing of logging events to the same file w/o corruption. I have been using log4j 1.2.x for a while for this purpose, and it's been working in a production environment for quite some time actually.
> What I did there is make my own DailyRollingSharedFileAppender (based on the old DailyRollingFileAppender) that contains some custom logic & locking to provide a safe mechanism for handling file rollovers on the shared files.
> I am currently in the process of upgrading to log4j2 for several reasons, and as such am working to re-implement this concept by making a couple of custom classes to augment log4j2 accordingly. Given the new architecture (which is very nice, BTW) I think this should actually a fairly straightforward process...
> 1) Create a SharedFileRenameAction that extends FileRenameAction (has my custom logic & locking)
> 2) Create a SharedFileRolloverStrategy that extends DefaultRolloverStrategy (no gz/zip support, uses SharedFileRenameAction)
> 3) Reference SharedFileRolloverStrategy in log4j2.xml for the appenders using shared files
> So for this, I only need to override a few things in these classes, and as such I'd rather extend them than completely write new ones. For #2 this is not an issue, but for #1 I have hit a snag:
> public final class FileRenameAction extends ActionBase
> (note: using beta-2 here, in trunk ActionBase is now AbstractAction)
> I've marked this issue as "Question" for now, so here is that question:
> Why is FileRenameAction marked final?
> If there was no intentional restriction on extensibility here, then I'd like to make this issue an "Improvement" instead, requesting that this class no longer have the final qualifier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org