[
https://issues.apache.org/jira/browse/ACCUMULO-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807642#comment-13807642
]
Mike Drob commented on ACCUMULO-1242:
-------------------------------------
A few comments on your code, Ed.
My version of maven (3.0.5) didn't seem to like that your test classes didn't
end with "Test" and refused to pick them up until I renamed them.
Also, my maven didn't package the Driver class until I moved it from src/test
into src/main. Then I was able to run the logDriver.sh script and it was pretty
cool to see.
I'm a bit hazy on why we need reflection in this and just using the slf4j
bindings wouldn't be enough. Do we directly set the log level anywhere outside
of the unit tests? If that's the case, I'd be fine with guilty knowledge in the
test classes about what framework we're using and setting levels explicitly
that way.
The FATAL levels can all be ERROR, I think, without losing too much granularity.
I don't have any ideas on how to handle the SendToChainsaw case... it looks
like that class is doing explicit parsing of the format to break it up into
whatever fields are expected. I suppose we can put that off for now and handle
it in a follow on issue, or ignore it entirely. If somebody else chooses to use
a different log4j implementation (of which there could be thousands) then I
don't think it is reasonable for us to attempt to parse their log files.
In short, I think you're headed in the right direction, but possibly attempting
to bite off more than anybody expects. Completely modularizing Accumulo logging
is a great goal, but we'd be happy with some cleaner dependencies as well, a
much lower hanging fruit.
> 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)
