[
https://issues.apache.org/jira/browse/ACCUMULO-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812208#comment-13812208
]
Ed Coleman commented on ACCUMULO-1242:
--------------------------------------
So far, in core, setLevel is used in the ClientOpts, Shell, OpTimer and classes
in org.apache.accumulo.core.client.mapred (AccumuloFileOutputFormat for
example), org.apache.accumulo.core.client.mapreduce (AccumuloInputFormat for
example) as well as unit tests.
The class org.apache.accumulo.core.util.OpTimer is called from different
places, usually with trace level logging (I think there was one example of it
being called with INFO, but that is in NativeMapStressTest)
The tests should not be a factor - the level could be set using test
configuration files
So there would be a little more to move than just CLI and there would need to
be some decisions / minor refactoring - certainly do-able.
My first objective was to get through it the first time using the reflection
based classes to replicate current behaviour and then using that as a marker
with the goal of eliminating it. Once it was no longer used or just local to
shell / cli we can evaluate what to do.
For example, it seems that the mapred and mapreduce classes should just use
normal log behaviour via config files / logging properties, but I'm not
familiar enough with those classes at this point to really say. This would
give us the option of either moving them and having them depended on log4j, or
having them use "normal" logging properties and then just use slf4j.
> Consistent logging
> ------------------
>
> Key: ACCUMULO-1242
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1242
> Project: Accumulo
> Issue Type: Bug
> Components: build
> Reporter: Christopher Tubbs
> Assignee: Ed Coleman
> Labels: log4j, logging, logs, slf4j
> Fix For: 1.7.0
>
> Attachments: accumulo-slf4j-snapshot.patch, dynamicLog.tgz
>
>
> Logging dependencies are very inconsistent. It seems we have absolute
> dependencies on log4j, yet use slf4j sometimes, and log4j other times. In
> some of our tests we have slf4j-nop as a test dependency.
> It seems we could consolidate a lot of this if we simply did:
> # slf4j-api : compile
> # slf4j-log4j12 : runtime
> # slf4j-nop : test
> # log4j : runtime
> We could do this in the parent POM and get rid of all the different
> dependencies throughout the code.
> I don't know that we could ever use anything other than slf4j-log4j12 as the
> implementation (unless our dependencies broke away from using log4j directly
> also), but at least we'd clean up all the logging dependencies in our
> code/build, and would be ready to switch to something better if something
> came along. Further, if somebody wanted to reuse our code, and weren't tied
> to log4j, because they didn't need our transitive dependencies that locked in
> log4j, they could easily depend on their own slf4j implementation jar, and
> all the logging in our code would still work correctly for them without
> needing to use something like log4j-over-slf4j.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
