[
https://issues.apache.org/jira/browse/LOG4J2-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223121#comment-15223121
]
Remko Popma commented on LOG4J2-1323:
-------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
