[
https://issues.apache.org/jira/browse/LUCENE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4713:
----------------------------------
Attachment: LUCENE-4713.patch
Hi Christian,
after some investigation I found out *why* the java.util.ServiceLoader simply
uses "null" but still always uses the system classloader: The reason is simple:
java.util.ServiceLoader is itsself loaded by the system classloader (as its in
rt.jar), so getCallerClassLoader() inside Class.forName() returns the system
classloader. So there is no need to have a special case in java.
The attached patch uses the system classloader if SPIClassIterator gets a null
one, so its 100% consistent.
But the change is not really needed, as Lucene's classloader is always != null,
because its no system class so we will never get into this detail. I just
changed it to be consistent.
Please note: getSystemClassLoader *may* return null - I am not sure if this
ever happens, the java code talks about compilation of rt.jar and such funny
things, so i think the null checks in the Class implementation is more for
bootstrapping the JVM, user code will never see a null system classloader.
In either case, there is no problem with the current code if it returns null:
its never called (haha) and it uses Class.forName, which supports null as
classloader.
> SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader
> fails
> --------------------------------------------------------------------------------
>
> Key: LUCENE-4713
> URL: https://issues.apache.org/jira/browse/LUCENE-4713
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.0, 4.1, 4.2
> Reporter: Christian Kohlschütter
> Assignee: Uwe Schindler
> Priority: Minor
> Labels: ClassLoader, Thread
> Fix For: 4.3
>
> Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch,
> LUCENE-4713.patch, 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() instead.
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
