[ 
https://issues.apache.org/jira/browse/LOG4J2-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233518#comment-15233518
 ] 

Dmitri Blinov commented on LOG4J2-1323:
---------------------------------------

If my experience with log4j2 may be of any help, I was once forced to 
reimplement a custom version of FileAppender/FileManager because in the project 
where log4j2 was used there was a requirement that webapp should write log 
files for each session separately in terms of file location and logging 
thresholds - each session was assumed to have its own level. Since there could 
be a lot of sessions and therefore a lot of simultaneously opened files, it was 
crucial for FileAppender to be able to open/close its file during each request. 
While this issue had nothing to do with privateness I'd rather avoided any such 
reimplementations in favour of more flexible basic logic, say we would once see 
suspend/resume methods for appenders in which file or socket or any other 
underlying resource could be closed and reopened.

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

Reply via email to