Description
conf/examples/1GB/native-standalone/accumulo-site.xml currently reads
<property> <name>general.classpaths</name> <value> <!-- Comment the following for hadoop-1.2 --> $HADOOP_PREFIX/share/hadoop/common/.*.jar, $HADOOP_PREFIX/share/hadoop/common/lib/.*.jar, $HADOOP_PREFIX/share/hadoop/hdfs/.*.jar, $HADOOP_PREFIX/share/hadoop/mapreduce/.*.jar, $HADOOP_PREFIX/share/hadoop/yarn/.*.jar, /usr/lib/hadoop/.*.jar, /usr/lib/hadoop/lib/.*.jar, /usr/lib/hadoop-hdfs/.*.jar, /usr/lib/hadoop-mapreduce/.*.jar, /usr/lib/hadoop-yarn/.*.jar, $ACCUMULO_HOME/lib/accumulo-server.jar, $ACCUMULO_HOME/lib/accumulo-core.jar, $ACCUMULO_HOME/lib/accumulo-start.jar, $ACCUMULO_HOME/lib/accumulo-fate.jar, $ACCUMULO_HOME/lib/accumulo-proxy.jar, $ACCUMULO_HOME/lib/[^.].*.jar, $ZOOKEEPER_HOME/zookeeper[^.].*.jar, $HADOOP_CONF_DIR, $HADOOP_PREFIX/[^.].*.jar, $HADOOP_PREFIX/lib/[^.].*.jar, </value> <description>Classpaths that accumulo checks for updates and class files.</description> </property>
this has the unusual property of sticking Hadoop jars before Accumulo jars on the classpath when using Hadoop 2.
we discovered this issue when one of our custom iterators loaded up the wrong version of guava (Hadoop 2.2.0's guava 11.0.2 instead of Accumulo 1.6.0-SNAPSHOT's guava 14) due to this ordering.