You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2013/12/06 05:29:35 UTC
[jira] [Comment Edited] (HBASE-10073) [Hadoop1]: hbase zkcli broken
due to slf4j incompatibility
[ https://issues.apache.org/jira/browse/HBASE-10073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840960#comment-13840960 ]
Andrew Purtell edited comment on HBASE-10073 at 12/6/13 4:27 AM:
-----------------------------------------------------------------
Do we care about calling zkcli from with HBase? Should ZK users call ZK CLI from their separate ZK install?
How about removing './bin/hbase zkcli'?
was (Author: apurtell):
Do we care about calling zkcli from with HBase? Should ZK users call ZK CLI from their separate ZK install?
> [Hadoop1]: hbase zkcli broken due to slf4j incompatibility
> ----------------------------------------------------------
>
> Key: HBASE-10073
> URL: https://issues.apache.org/jira/browse/HBASE-10073
> Project: HBase
> Issue Type: Bug
> Components: Zookeeper
> Affects Versions: 0.96.1
> Environment: Centos6, sun-jdk-64bit-1.7.0.25
> Reporter: Aleksandr Shulman
> Assignee: Andrew Purtell
> Fix For: 0.98.0, 0.96.1, 0.99.0
>
>
> Observed behavior:
> In my automation, I have a call to hbase zkcli. That call recently broke with this checkin: https://github.com/apache/hbase/commit/5af0a60efed91ac2084f25f13edb21db0f510e7c
> The error that is reported is:
> {code}++ ./hbase zkcli
> 11:19:58 Warning: $HADOOP_HOME is deprecated.
> 11:19:58
> 11:20:00 Exception in thread "main" java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory
> 11:20:00 at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
> 11:20:00 at org.apache.zookeeper.ZooKeeperMain.<clinit>(ZooKeeperMain.java:50)
> 11:20:00 at org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServer.main(ZooKeeperMainServer.java:78)
> 11:20:00 Build step 'Execute shell' marked build as failure{code}
> That said, this checkin is perfectly valid as each component should be allowed to specify its own dependencies.
> The issue is a deeper one of dependency mismatches.
> Note: This issue only affects hadoop1, not hadoop2. It also appears in trunk, where there is a similar checkin, but since trunk is not required to work against hadoop1, this is not an issue for trunk.
--
This message was sent by Atlassian JIRA
(v6.1#6144)