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 "Remko Popma (JIRA)" <ji...@apache.org> on 2016/04/03 06:54:25 UTC
[jira] [Comment Edited] (LOG4J2-1323) Remove Final Declarations on
Many Classes/Methods
[ https://issues.apache.org/jira/browse/LOG4J2-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223121#comment-15223121 ]
Remko Popma edited comment on LOG4J2-1323 at 4/3/16 4:53 AM:
-------------------------------------------------------------
I agree with Gary. I have a long-standing desire to refactor the current file roll-over behaviour (LOG4J2-1198), and opening things up would make that harder if not impossible.
Would it be possible to focus a bit more on the problem you are trying to solve rather than the solution (to subclass RollingFileAppender/Manager)?
{quote}
I need to force a very specific JSON format that isn't conducive to the integrated JsonLayout class.
{quote}
I assume you created a custom Layout (hopefully extending AbstractLayout, because the Layout interface will have an additional method in 2.6).
{quote}
Additionally, we want to enforce standard values for the log file name, rollover policies, etc. Most of these fields are pulled via configuration obtained at runtime (...)
{quote}
The only way I can think of to really _enforce_ configuration elements is to do [programmatic configuration|http://logging.apache.org/log4j/2.x/manual/customconfig.html]. You could first read in the "untrusted" configuration, and after that let your programmatic configuration logic examine this and replace certain values with approved values. This would be cleaner, more powerful, and less likely to break when the Log4j internals change.
was (Author: remkop@yahoo.com):
I agree with Gary. I have a long-standing desire to refactor the current file roll-over behaviour (LOG4J2-1198), and opening things up would make that harder if not impossible.
Would it be possible to focus a bit more on the problem you are trying to solve rather than the solution (to subclass RollingFileAppender/Manager)?
{quote}
I need to force a very specific JSON format that isn't conducive to the integrated JsonLayout class.
{quote}
I assume you created a custom Layout (hopefully extending AbstractLayout, because the Layout method will have an additional method in 2.6).
{quote}
Additionally, we want to enforce standard values for the log file name, rollover policies, etc. Most of these fields are pulled via configuration obtained at runtime (...)
{quote}
The only way I can think of to really _enforce_ configuration elements is to do [programmatic configuration|http://logging.apache.org/log4j/2.x/manual/customconfig.html]. You could first read in the "untrusted" configuration, and after that let your programmatic configuration logic examine this and replace certain values with approved values. This would be cleaner, more powerful, and less likely to break when the Log4j internals change.
> Remove Final Declarations on Many Classes/Methods
> -------------------------------------------------
>
> Key: LOG4J2-1323
> URL: https://issues.apache.org/jira/browse/LOG4J2-1323
> Project: Log4j 2
> Issue Type: Wish
> Components: API, Appenders, Pattern Converters
> Affects Versions: 2.5
> Reporter: Andrew Bernhagen
> Labels: architecture, easyfix, newbie, patch
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Within my organization, I've had to develop a custom appender that automatically configures certain properties and a specific layout to tie into other initiatives we have tied to logging. Log4j2 made this much more difficult than Log4j1 due to the use of final on many classes (e.g. the appender implementations) and methods (all pattern layout methods). This has made extension overly difficult and filled with a lot of copy and paste that I'd rather not have. Is it possible that these could be removed to make it easier to extend the existing implementations?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org