[
https://issues.apache.org/jira/browse/RATIS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963515#comment-16963515
]
Henrik Hegardt edited comment on RATIS-508 at 10/30/19 11:32 PM:
-----------------------------------------------------------------
The problem is when you declare a dependency in DM you also set a precedence on
how Maven should resolve transitive dependencies. It set's a default behavior
on how the dependencies should be resolved, not only version, but also scope.
The main goal is to not have a dependency on log4j at all since we want to let
the users to chose the logging implementation. But due to historical and
practical means ratis is using log4j for logging purposes when the tests are
run, which is of course, fine. If declared in the DM section it should
therefore have scope test, logically. Though this means that to override that
scope, one need to explicitly define some other scope, like compile, directly
in the pom.
Since log4j is declared in test scope in DM, this would mean that like the
ratis-hadoop module now will have it's transitive dependency on log4j be in
scope test as well, meaning that in runtime, that Maven will have omitted
log4j, which I think is not what we want. This forces the user to manually add
log4j as a dependency if they are going to use the ratis-hadoop module.
If we remove the test scope from log4j in DM, and run it "default" with compile
scope would mean that we need to declare scope test locally in all modules to
make sure its not included accidentally.
To remedy the test scoped DM configuration, one could declare log4j as a
dependency in the pom to make sure it gets the right scope, though that would
mean one declares not direct code dependencies in the pom, which is not best
practice, and IMHO pollutes the pom file.
The other solution is to revert the DM declaration and just simply use a
property to set the version and use that to manage the version. OTOH log4j
1.2.x is pretty much discontinued in favor of log4j 2 so I don't think that
version will ever change, and the slf4j-log4j binding will make sure the right
log4j version is imported since it needs that to bridge from slf4j.
Another thing is that the test code uses log4j directly pretty much, which is
why some modules has lo4j declared as a test scoped dependency, and I think it
that should also be reduced in the future. And if that happens, log4j could be
removed/replaced entirely.
I hope this is understandable :)
was (Author: hheg):
The problem is when you declare a dependency in DM you also set a precedence on
how Maven should resolve transitive dependencies. It set's a default behavior
on how the dependencies should be resolved, not only version, but also scope.
The main goal is to not have a dependency on log4j at all since we want to let
the users to chose the logging implementation. But due to historical and
practical means ratis is using log4j for logging purposes when the tests are
run, which is of course, fine. If declared in the DM section it should
therefore have scope test, logically. Though this means that to override that
scope, one need to explicitly define some other scope, like compile, directly
in the pom.
Since log4j is declared in test scope in DM, this would mean that like the
ratis-hadoop module now will have it's transitive dependency on log4j be in
scope test as well, meaning that in runtime, that Maven will have omitted
log4j, which I think is not what we want. This forces the user to manually add
log4j as a dependency if they are going to use the ratis-hadoop module.
If we remove the test scope from log4j in DM, and run it "default" with compile
scope would mean that we need to declare scope test locally in all modules to
make sure its not included accidentally.
To remedy the test scoped DM configuration, one could declare log4j as a
dependency in the pom to make sure it gets the right scope, though that would
mean one declares not direct code dependencies in the pom, which is not best
practice, and IMHO pollutes the pom file.
The other solution is to revert the DM declaration and just simply use a
property to set the version and use that to manage the version. OTOH log4j
1.2.x is pretty much discontinued in favor of log4j 2 so I don't think that
version will ever change, and the slf4j-log4j binding will make sure the right
log4j version is imported since it needs that to bridge from slf4j.
Another thing is that the test code uses log4j directly pretty much, which is
why some has lo4j declared as a test scoped dependency, and I think it that
should also be reduced in the future. And if that happens, log4j could be
removed/replaced entirely.
I hope this is understandable :)
> Switch from log4j to slf4j
> --------------------------
>
> Key: RATIS-508
> URL: https://issues.apache.org/jira/browse/RATIS-508
> Project: Ratis
> Issue Type: Improvement
> Components: common
> Affects Versions: 0.4.0
> Reporter: Hai Zhou
> Assignee: Henrik Hegardt
> Priority: Major
> Fix For: 0.5.0
>
> Attachments: RATIS-508.001.patch, RATIS-508.002.patch
>
>
> Improve the request to raise the abstraction level of our logging framework
> so that logging is done through slf4j instead of directly through log4j.
> This will allow users to swap-out the underlying logging framework, giving a
> choice of log4j, logback-classic, and log4j2.
> eg.
> In my project, I use logback, which conflicts with log4j.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
