logging-log4j-dev mailing list archives

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

    [ 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
> 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

View raw message