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 "David Johle (JIRA)" <ji...@apache.org> on 2012/11/12 19:09:12 UTC
[jira] [Created] (LOG4J2-112) Why is FileRenameAction a final
class?
David Johle created LOG4J2-112:
----------------------------------
Summary: 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
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 similar to 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 (and maybe some others like it) 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500021#comment-13500021 ]
Ralph Goers commented on LOG4J2-112:
------------------------------------
I'm unclear on what still needs to be done with this issue.
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508919#comment-13508919 ]
Gary Gregory commented on LOG4J2-112:
-------------------------------------
Do you think this action is generally useful? Do you want to submit it as 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: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Fix For: 2.0-beta3
>
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495481#comment-13495481 ]
Gary Gregory commented on LOG4J2-112:
-------------------------------------
Note that final classes perform faster /because/ they cannot be extended. Your mileage may vary.
> 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
[jira] [Comment Edited] (LOG4J2-112) Why is FileRenameAction a
final class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495519#comment-13495519 ]
David Johle commented on LOG4J2-112:
------------------------------------
Yes, there are some debates about the performance increases of using final for methods/classes...
A final method (or method of a class marked final) call can avoid some internal lookup steps because there is no need to check for overrides/etc. However, several people point out that this sort of optimization is now performed automatically at runtime by some VMs for a class not marked final that is also not extended by anything. So if that is the case, performance difference could become mostly irrelevant.
Furthermore, this is the rename action, which I believe is only called when a rollover is triggered, which is a relatively infrequent call (at least when comparing it to something like the logging event methods). This just reduces the value of any marginal performance gains/losses that result from adding this capability.
Now, to expand further on this topic, I have run into a snag on my item #2 as well. The purge() method is private, not protected. So that means no extending on that front as well.
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Attachment: make_FileRenameAction_extensible.patch
Patch to make the FileRenameAction class extensible.
This includes:
1) Allow subclassing (no final keyword on class)
2) Allow subclass access to status logger
3) Keep no-arg execute() method from being overridden
4) Allow sublclass access (but no overrides) to copyFile() method
> 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
> Attachments: make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508893#comment-13508893 ]
David Johle commented on LOG4J2-112:
------------------------------------
It's fixed, and did help in the beginning. But my final outcome for what I was trying to do was to make a renaming action of my own (based on beta3 code) ...
SharedFileRenameAction extends AbstractAction
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Fix For: 2.0-beta3
>
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Description:
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 (and maybe some others like it) no longer have the final qualifier.
was:
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 similar to 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 (and maybe some others like it) no longer have the final qualifier.
> 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 (and maybe some others like it) 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495601#comment-13495601 ]
Gary Gregory commented on LOG4J2-112:
-------------------------------------
I removed final keyword on class declaration in trunk.
The execute() instance method was already public, no change needed there.
But before we proceed, I wonder about the current implementation. Why are there static methods on the class when their only call sites are in instance methods? Is that inherited from 1.2 or is {{execute(File, File, boolean)}} really designed to be reused? From where? Same question about the static methods on the other classes in the package.
I think we should leave LOGGER private; all is does is {{LOGGER = StatusLogger.getLogger();}} and that could be in-lined later or whatnot. It's easy enough for anyone to use. If we are going to to something like that, we might as well pull it up to AbstractAction.
Actually... AbstractAction already has a protected LOGGER. I'm going to clean up the subclasses, no need for duplication.
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Resolved] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle resolved LOG4J2-112.
--------------------------------
Resolution: Implemented
Fix Version/s: 2.0-beta3
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Fix For: 2.0-beta3
>
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495478#comment-13495478 ]
Ralph Goers commented on LOG4J2-112:
------------------------------------
"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
[jira] [Comment Edited] (LOG4J2-112) Why is FileRenameAction a
final class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495568#comment-13495568 ]
David Johle edited comment on LOG4J2-112 at 11/12/12 7:54 PM:
--------------------------------------------------------------
Patch to allow subclasses to override the DefaultRolloverStrategy.purge() method as well.
was (Author: djohle):
Patch to allow subclasses to override the purge() method as well.
> 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
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495495#comment-13495495 ]
Ralph Goers commented on LOG4J2-112:
------------------------------------
Do you have a link to something on that Gary? I would love to read about it.
That said, in this case I would think the value in making it extensible would outweigh whatever performance gain their might be.
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Description:
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.
was:
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 (and maybe some others like it) no longer have the final qualifier.
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Issue Type: Improvement (was: Question)
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508124#comment-13508124 ]
Ralph Goers commented on LOG4J2-112:
------------------------------------
Is there anything left to do on this or can it be closed?
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495606#comment-13495606 ]
Gary Gregory commented on LOG4J2-112:
-------------------------------------
For the above:
commit -m "[LOG4J2-112] Why is FileRenameAction a final class? Remove final keyword on class declaration." C:/svn/org/apache/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/appender/rolling/helper/FileRenameAction.java
Sending C:/svn/org/apache/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/appender/rolling/helper/FileRenameAction.java
Transmitting file data ...
Committed revision 1408440.
commit -m "FileRenameAction's superclass already declares a protected LOGGER as "StatusLogger.getLogger()"" C:/svn/org/apache/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/appender/rolling/helper/FileRenameAction.java
Sending C:/svn/org/apache/log4j2/trunk/core/src/main/java/org/apache/logging/log4j/core/appender/rolling/helper/FileRenameAction.java
Transmitting file data ...
Committed revision 1408446.
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495574#comment-13495574 ]
David Johle commented on LOG4J2-112:
------------------------------------
The patches uploaded are based on the 2.0-beta2 tag. If you need patches for trunk code, let me know and I'll re-make them accordingly.
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495526#comment-13495526 ]
Ralph Goers commented on LOG4J2-112:
------------------------------------
If you provide a patch, changing the purge method from private to protected would be fine.
> 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: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Comment Edited] (LOG4J2-112) Why is FileRenameAction a
final class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495568#comment-13495568 ]
David Johle edited comment on LOG4J2-112 at 11/12/12 7:54 PM:
--------------------------------------------------------------
Patch to allow subclasses to override the purge() method as well.
was (Author: djohle):
Allow subclasses to override the purge() method as well.
> 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
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495624#comment-13495624 ]
David Johle commented on LOG4J2-112:
------------------------------------
Very nice, that does make it even cleaner.
As I'm working on this, I'm starting to think I might end up making my Strategy entirely instead of extending the DefaultRolloverStrategy.
Still up in the air on this, and running into other fun stuff like PatternProcessor.formatFileName() being protected, forcing me to make my new class within a log4j package hierarchy instead of my own/etc.
> Why is FileRenameAction a final class?
> --------------------------------------
>
> Key: LOG4J2-112
> URL: https://issues.apache.org/jira/browse/LOG4J2-112
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta2
> Reporter: David Johle
> Priority: Minor
> Labels: features
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Commented] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "Gary Gregory (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495535#comment-13495535 ]
Gary Gregory commented on LOG4J2-112:
-------------------------------------
I don't recall where I first heard of 'final' and performance but I've seen the difference first hand. You have to be in some pretty tight looping code for it make a difference I would imagine.
> 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: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Attachment: make_DefaultRolloverStrategy_purge_extensible.patch
Allow subclasses to override the purge() method as well.
> 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
> Attachments: make_DefaultRolloverStrategy_purge_extensible.patch, make_FileRenameAction_extensible.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> 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
[jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final
class?
Posted by "David Johle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Johle updated LOG4J2-112:
-------------------------------
Remaining Estimate: 3h (was: 5m)
Original Estimate: 3h (was: 5m)
> 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: 3h
> Remaining Estimate: 3h
>
> 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