logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1323) Remove Final Declarations on Many Classes/Methods
Date Sun, 03 Apr 2016 04:54:25 GMT

    [ 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


Mime
View raw message