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

Dhiraj Kumar commented on HIVE-15531:
-------------------------------------

[~sershe], I dug the bug deeper and found out that it was our environmental 
issue. There were two problem at our end,

1. An UDF jar in near beginning of classpath with log4j (1.2) classes in it. It 
was picked by Commons-logger. 
2. Another jar, having a basic log4j.properties was picked for properties since 
hive configuration directory (top in class path) was missing log4j.properties 
and was having log4j2.properties. 

So, even without log4j-jcl (current patch), it may work fine. Since 
log4j-1.2-api (already part of hive 2.x) has org.apache.log4j.Logger class and 
initialises it properly with log4j2 configuration. That works like bridge. 
Provided there is no other class in class path before log4j-1.2-api which has 
org.apache.log4j.Logger class. 

log4j-jcl overcomes classpath issue since commons-logging tries to find 
LogFactory and log4j-jcl injects itself there. So there won't be any classpath 
issue with it. Code snippet below from org.apache.commons.logging.LogFactory

{code}
// Second, try to find a service by using the JDK1.3 class
        // discovery mechanism, which involves putting a file with the name
        // of an interface class in the META-INF/services directory, where the
        // contents of the file is a single line specifying a concrete class
        // that implements the desired interface.

        if (factory == null) {
            if (isDiagnosticsEnabled()) {
                logDiagnostic("[LOOKUP] Looking for a resource file of name [" 
+ SERVICE_ID +
                              "] to define the LogFactory subclass to use...");
            }
            try {
                final InputStream is = getResourceAsStream(contextClassLoader, 
SERVICE_ID);
{code}

Since this issue reflects itself based on classpath, I am thinking to inject 
log4j 1.2 in classpath with test scope and check that right class has been 
loaded by Commons logging. 
Would like to know your thoughts. 











> Hive breaks Hadoop commons logging with log4j2
> ----------------------------------------------
>
>                 Key: HIVE-15531
>                 URL: https://issues.apache.org/jira/browse/HIVE-15531
>             Project: Hive
>          Issue Type: Bug
>    Affects Versions: 2.1.0
>            Reporter: Dhiraj Kumar
>            Assignee: Dhiraj Kumar
>            Priority: Minor
>         Attachments: HIVE-15531.patch
>
>
> Hadoop (2.7), which is using Commons-logging is not compatible with log4j2 
> without bridge. 
> The bridge is missing in Hive. 
> This leads to a problem whereby commons-logging initialises a log4j (1.2) 
> version, does not configure it properly since configuration for it is missing 
> and sends logging output to stdout (the default). 



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

Reply via email to