[
https://issues.apache.org/jira/browse/LOG4J2-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924804#comment-13924804
]
Remko Popma commented on LOG4J2-562:
------------------------------------
I had a look at the attached patch. It looks like this is a single patch for a
number of initiatives. It may be better to split this up so they can be
considered in isolation. Is it possible to separate the Writer/OutputStream
related changes from the LoggerExtension changes?
The idea of the {{LoggerExtension}} and {{ExtensibleLogger}} interfaces is
interesting. It does automatically provide the correct FQCN for custom/extended
loggers. On the other hand, the proposed interfaces and methods add quite a bit
of public API surface and their use may be harder to understand than simply
extending AbstractLogger or AbstractLoggerWrapper. Also, the proposed solution
sometimes helps to reduce code (SLF4JLogger in the patch), but sometimes
requires more code (jcl/Log4jLog in the patch). So I'm not sure that the
overall trade-off is a good one, especially since extending loggers will be
fairly rare...
Do you think the delegation idea proposed in LOG4J2-555 will be useful in the
Writers/OutputStreams? I'll try to flesh out that idea to make it more concrete.
> Improve ability to create custom extended logger
> ------------------------------------------------
>
> Key: LOG4J2-562
> URL: https://issues.apache.org/jira/browse/LOG4J2-562
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Reporter: Bruce Brouwer
> Attachments: log4j2-loggerExtension.patch
>
>
> Create a LoggerExtension from the original logger which simply remembers the
> FQCN that will ultimately be the extension.
> Also by doing this, we can switch a bunch of methods that ended up being
> public back to protected. I'm guessing they became public so extensions could
> call them.
> This can simplify extensions (such as slf4j, jcl, custom extensions, logger
> streams) so they don't have to pass in the FQCN to that special log method on
> AbstractLogger anymore. Also, you don't have to wrap every extended log
> method with a check to see if the logging is enabled. Finally, you don't need
> to have any access to the MessageFactory. This even has to potential to
> eliminate AbstractLoggerWrapper.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
