Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # user >> jarFilePath for HTableDescriptor.addCoprocessor() with 0.94.2 vs 0.94.4


+
James Taylor 2013-02-12, 00:07
Copy link to this message
-
Re: jarFilePath for HTableDescriptor.addCoprocessor() with 0.94.2 vs 0.94.4
This is due to HBASE-7205 (https://issues.apache.org/jira/browse/HBASE-7205)
The new behavior is correct, but it does represent a slight change in behavior.

The difference is that previously we tried to load the class first, if it was in the system classpath we'll find it there. Now we only load from the system classpath when no jar file was specified (again, this is the correct but different behavior).

-- Lars

________________________________
From: James Taylor <[EMAIL PROTECTED]>
To: HBase User <[EMAIL PROTECTED]>
Sent: Monday, February 11, 2013 4:07 PM
Subject: jarFilePath for HTableDescriptor.addCoprocessor() with 0.94.2 vs 0.94.4

In 0.94.2, if the coprocessor class was on the HBase classpath, then the jarFilePath argument to HTableDescriptor.addCoprocessor seemed to essentially be ignored - it didn't matter if the jar could be found or not. In 0.94.4 we're getting an error if this is the case. Is there a way to continue to get the old behavior? We've got HTables that were created under 0.94.2 in which scans will stop working if we upgrade to 0.94.4 because our coprocessors will no longer be found.

Thanks,

    James
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB