[ 
https://issues.apache.org/jira/browse/ACCUMULO-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13812183#comment-13812183
 ] 

Sean Busbey commented on ACCUMULO-1242:
---------------------------------------

Can we refactor the CLI into a separate module and then just have that module 
(and tests) use log4j? That would allow people building on e.g. client code to 
be free of us dictating how they log.

I'd really like to avoid reflection and rely on the bindings that slf4j 
provides.

> 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)

Reply via email to