[
https://issues.apache.org/jira/browse/LOG4J2-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers updated LOG4J2-39:
------------------------------
Description:
Curt added a @doubt to Logger that states "interface so complicated indepenent
implementation unlikely. Should be refactored." and in AbstractLogger "See
comments on Logger, interface is so complex that unlikely to be independently
implemented." LogMF/LogSF separates those concerns out of Logger.
An API is for the convenience of the caller, not the implementor. The API has
many variations of the same method for that reason. In addition, many of them
exist simply to make the API perform better as varargs, while convenient,
perform poorly. In addition, the observation that the interface is "so complex
that it is unlikely to be independently implemented" is unfounded. Creating a
new implementation requires extending AbstractLogger and implementing the log
method and 8 isEnabled methods. That isn't terribly hard at all.
While LogMF and LogSF "simplify" the Logger interface they complicate life for
users of the API by requiring a wrapper API. In fact, the part that makes
AbstractLogger "complicated" is that it implements all these public methods so
that implementations don't have to. The formatting issues that LogMF and LogSF
try to solve are delegated to the Message objects in my implementation - a
solution I find much more satisfying.
In the end, including the methods in the Logger API or in separate static
wrapper methods is simply a matter of opinion.
was:
Curt added a @doubt to Logger that states "interface so complicated indepenent
implementation unlikely. Should be refactored." and in AbstractLogger "See
comments on Logger, interface is so complex that unlikely to be independently
implemented." LogMF/LogSF separates those concerns out of Logger.
An API is for the convenience of the caller, not the implementor. The API has
many variations of the same method for that reason. In addition, many of them
exist simply to make the API perform better as varargs, while convenient,
perform poorly. In addition, the observation that the interface is "so complex
that it is unlikely to be independently implemented" is unfounded. Creating a
new implementation requires extending AbstractLogger and implementing the log
method and 8 isEnabled methods. That isn't terribly hard at all.
> Logger in rgoers/log4j2-api is too complicated.
> -----------------------------------------------
>
> Key: LOG4J2-39
> URL: https://issues.apache.org/jira/browse/LOG4J2-39
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Reporter: Ralph Goers
>
> Curt added a @doubt to Logger that states "interface so complicated
> indepenent implementation unlikely. Should be refactored." and in
> AbstractLogger "See comments on Logger, interface is so complex that unlikely
> to be independently implemented." LogMF/LogSF separates those concerns out
> of Logger.
> An API is for the convenience of the caller, not the implementor. The API has
> many variations of the same method for that reason. In addition, many of them
> exist simply to make the API perform better as varargs, while convenient,
> perform poorly. In addition, the observation that the interface is "so
> complex that it is unlikely to be independently implemented" is unfounded.
> Creating a new implementation requires extending AbstractLogger and
> implementing the log method and 8 isEnabled methods. That isn't terribly hard
> at all.
> While LogMF and LogSF "simplify" the Logger interface they complicate life
> for users of the API by requiring a wrapper API. In fact, the part that makes
> AbstractLogger "complicated" is that it implements all these public methods
> so that implementations don't have to. The formatting issues that LogMF and
> LogSF try to solve are delegated to the Message objects in my implementation
> - a solution I find much more satisfying.
> In the end, including the methods in the Logger API or in separate static
> wrapper methods is simply a matter of opinion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
