[
https://issues.apache.org/jira/browse/LUCENE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561231#comment-13561231
]
Uwe Schindler commented on LUCENE-4713:
---------------------------------------
I don't think you have a chance to not set the correct context classloader...
Lucene is not the only this that relies on this (XML parser SPIs,
java.security, imaging file formats, Charsets, ...)
Using more than one class loader to lookup SPIs is possible but violates the
spec. It also slows down, because you have to do several lookups, filter
duplicates and so on.
One thing you can do is: Codec.reloadCodescs(yourClassloader),
PostingFormat.reloadPostingsFormats(yourClassLoader) before using Lucene (and
the same for the other SPIs in Lucene). This will rescan the given classloader
and add new, additional codecs found to the internal list. Solr is doing the
same after initializing the SolrResourceLoader (to allow codecs be loaded from
the Solr plugins folder).
I already have the plans to add one Util class that does this for all SPIs,
Lucene uses (currently you have to do this separately for all of them).
> Replace calls to Thread#getContextClassLoader with the ClassLoader of the
> current class
> ---------------------------------------------------------------------------------------
>
> 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
> Priority: Minor
> Labels: ClassLoader, Thread
> Attachments: LuceneContextClassLoader.patch
>
>
> 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]
