[
https://issues.apache.org/jira/browse/HBASE-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408437#comment-13408437
]
Hadoop QA commented on HBASE-6308:
----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12535401/6308-v2.txt
against trunk revision .
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
+1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.
+1 javadoc. The javadoc tool did not generate any warning messages.
-1 javac. The applied patch generated 5 javac compiler warnings (more than
the trunk's current 4 warnings).
-1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/2337//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2337//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2337//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/2337//console
This message is automatically generated.
> Coprocessors should be loaded in a custom ClassLoader to prevent dependency
> conflicts with HBase
> ------------------------------------------------------------------------------------------------
>
> Key: HBASE-6308
> URL: https://issues.apache.org/jira/browse/HBASE-6308
> Project: HBase
> Issue Type: Improvement
> Components: coprocessors
> Affects Versions: 0.92.1, 0.94.0
> Reporter: James Baldassari
> Fix For: 0.96.0
>
> Attachments: 6308-v2.txt, HBASE-6308-0.92.patch,
> HBASE-6308-trunk.patch
>
>
> Currently each coprocessor is loaded with a URLClassLoader that puts the
> coprocessor's jar at the beginning of the classpath. The URLClassLoader
> always tries to load classes from the parent ClassLoader first and only
> attempts to load from its own configured URLs if the class was not found by
> the parent. This class loading behavior can be problematic for coprocessors
> that have common dependencies with HBase but whose versions are incompatible.
> For example, I have a coprocessor that depends on a different version of
> Avro than the version used by HBase. The current class loading behavior
> results in NoSuchMethodErrors in my coprocessor because some Avro classes
> have already been loaded by HBase, and the ClassLoader for my coprocessor
> picks up HBase's loaded classes first.
> My proposed solution to this problem is to use a custom ClassLoader when
> instantiating coprocessor instances. This custom ClassLoader would always
> attempt to load classes from the coprocessor's jar first and would only
> delegate to the parent ClassLoader if the class were not found in the
> coprocessor jar. However, certain classes would need to be exempt from this
> behavior. As an example, if the Copcoessor interface were loaded by both the
> region server's ClassLoader and the coprocessor's custom ClassLoader, then
> the region server would get a ClassCastException when attempting to cast the
> coprocessor instance to the Coprocessor interface. This problem can be
> avoided by defining a set of class name prefixes that would be exempt from
> loading by the custom ClassLoader. When loading a class, if the class starts
> with any of these prefixes (e.g. "org.apache.hadoop"), then the ClassLoader
> would delegate immediately to the parent ClassLoader.
> I've already implemented a patch to provide this functionality which I'll
> attach shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
