Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 28 Oct 2013 04:20:30 +0000 (UTC)
From: "Ed Coleman (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12640880.1365113057056.9594.1382934030526@arcas>
In-Reply-To: <JIRA.12640880.1365113057056@arcas>
References: <JIRA.12640880.1365113057056@arcas>
Subject: [jira] [Updated] (ACCUMULO-1242) Consistent logging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ACCUMULO-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ed Coleman updated ACCUMULO-1242:
---------------------------------

    Attachment: dynamicLog.tgz

The attachment contains a proof of concept for supporting dynamic log levels at runtime while having only slf4j as a compile time dependency.  I made it a stand-alone maven project for evaluation and to spur discussion on the approach.

A few notes:

I took a guess at what an acceptable package structure would be, starting with the assumption that the code would go under accumulo-core.  When integrated, I'm assuming that the test-xxx sub-projects will be eliminated.

The script dynamicLog/dynamic-logging-core/scripts/logDriver.sh is a simple test driver to validate the approach.

The test-log4j, and test-logback sub-projects allowed for junit testing by specifying the log framework as test dependencies in the sub project.  (an alternative approach could have been to use profiles, eliminating the need for sub-projects, but this seemed to make the log package being used explicit.)

>From examining the accumulo code base, this seems like it should cover most cases where log4j setLevel(Level X) is called directly. However, there are going to be some issues with the SendToChainsaw class as well as anywhere FATAL is used as a level (FATAL is not explicitly supported in logback.)

If this approach is acceptable, I'll work on submitting a proper patch with things merged into the code base and then start on converting things over.


> 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: Mike Drob
>              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)