lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails
Date Tue, 12 Mar 2013 10:53:12 GMT


Uwe Schindler commented on LUCENE-4713:

bq. Regarding overriding Lucene's default codec implementations: We anyways have to place
any other modified, non-SPI Lucene classes in the same ClassLoader, so I really appreciate
that this patch enforces this.

Overriding default Lucene Codecs doesn't need to necessarily use the same class name. Codecs
are identified by their "name" as written into the index files (e.g., "Lucene42"). If you
implement another subclass of Codec with the same name, but different class name, it is also
taken into account. But in any case, the class file must be listed before the lucene-core.jar
one in classpath (btw, this is used in Lucene 4.x, to allow a READ/WRITE variant of the Lucene3x
codec for testing only. The test-framework.jar simply exposes another class, extending the
original READONLY Lucene3x codec to support WRITE, but makeing it available also with the
"Lucene3x" name to the loader).
> SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails
> --------------------------------------------------------------------------------
>                 Key: LUCENE-4713
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>    Affects Versions: 4.0, 4.1, 4.2
>            Reporter: Christian Kohlschütter
>            Priority: Minor
>              Labels: ClassLoader, Thread
>             Fix For: 4.3
>         Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, LuceneContextClassLoader.patch
> NOTE: This issue has been renamed from:
> "Replace calls to Thread#getContextClassLoader with the ClassLoader of the current class"
> because the revised patch provides a clean fallback path.
> I am not sure whether it is a design decision or if we can indeed consider this a bug:
> In core and analysis-common some classes provide on-demand class loading using SPI. In
NamedSPILoader, SPIClassIterator, ClasspathResourceLoader and AnalysisSPILoader there are
constructors that use the Thread's context ClassLoader by default whenever no particular other
ClassLoader was specified.
> Unfortunately this does not work as expected when the Thread's ClassLoader can't see
the required classes that are instantiated downstream with the help of Class.forName (e.g.,
Codecs, Analyzers, etc.).
> That's what happened to us here. We currently experiment with running Lucene 2.9 and
4.x in one JVM, both being separated by custom ClassLoaders, each seeing only the corresponding
Lucene version and the upstream classpath.
> While NamedSPILoader and company get successfully loaded by our custom ClassLoader, their
instantiation fails because our Thread's Context-ClassLoader cannot find the additionally
required classes.
> We could probably work-around this by using Thread#setContextClassLoader at construction
time (and quickly reverting back afterwards), but I have the impression this might just hide
the actual problem and cause further trouble when lazy-loading classes later on, and potentially
from another Thread.
> Removing the call to Thread#getContextClassLoader would also align with the behavior
of AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, which in fact uses Attribute#getClass().getClassLoader()
> A simple patch is attached. All tests pass.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message