[
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: [email protected]
For additional commands, e-mail: [email protected]
