You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2010/05/30 09:09:36 UTC
[jira] Updated: (LOG4J2-39) Logger in rgoers/log4j2-api is too
complicated.
[ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org