logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Johle (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-112) Why is FileRenameAction a final class?
Date Mon, 12 Nov 2012 19:49:13 GMT

     [ 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


Mime
View raw message