[
https://issues.apache.org/jira/browse/ACCUMULO-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807655#comment-13807655
]
Ed Coleman commented on ACCUMULO-1242:
--------------------------------------
I don't have my VM fired up, so just going on memory. I'll dig out concrete
references later.
The biggest case is where we can set the log level to trace from the shell
(trace on / off)- and I don't think that we can give that up.
The other place where setLevel is called is when the log level is read from the
job configuration - this caused me to add the ability to use integers because
that seems to be what the job configuration is providing, although I think it
would be better to use names (debug, warn...) Either way this code can handle
both.
Without reflection, I think that we would need to have a separate jar for
runtime for each framework (sort of like slf4j-log4j jar) and that just seemed
messy. The few methods / classes where reflection was required seem pretty
stable and have been consistent for a long time. This provides the benefit of
being version independent - in case someone needs a particular version of log4j
for example, this approach should handle it without code changes, whatever
log4j or logback version is on the classpath will be used.
The best way that I found was to do a search on setLevel - and I was surprised
how many places it was actually called.
> 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: 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)
