Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 29 Jan 2015 22:32:34 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12771157.1422570718000.209932.1422570754482@Atlassian.JIRA>
In-Reply-To: <JIRA.12771157.1422570718000@Atlassian.JIRA>
References: <JIRA.12771157.1422570718000@Atlassian.JIRA>
 <JIRA.12771157.1422570718839@arcas>
Subject: [jira] [Created] (ACCUMULO-3544) accumulo-start uses log4j before
 it is initialized
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Christopher Tubbs created ACCUMULO-3544:
-------------------------------------------

             Summary: accumulo-start uses log4j before it is initialized
                 Key: ACCUMULO-3544
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3544
             Project: Accumulo
          Issue Type: Bug
          Components: start
            Reporter: Christopher Tubbs


Classes in the accumulo-start module appear to incorrectly use the log4j system before it is properly initialized.

ACCUMULO-2628 appears to have introduced it to start's Main class, but it looks like it's been around awhile in the AccumuloClassLoader and the new vfs class loader.

The output of these loggers will probably not go where we expect them to go, based on our custom log4j configuration files... certainly not before we execute the code to initialize log4j based on those configuration files. Hopefully, they will default to the console logger and get logged to the .out and .err files, but if there's a log4j.properties or log4j.xml file in the classpath, they could redirect these errors to somewhere else and we may not see them.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)