[
https://issues.apache.org/jira/browse/LUCENE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561463#comment-13561463
]
Christian Kohlschütter edited comment on LUCENE-4713 at 1/24/13 7:32 AM:
-------------------------------------------------------------------------
Revised patch.
Now uses Thread#getContextClassLoader and falls back to the default ClassLoader
on ClassNotFoundException/missing resource only, with the help of a lightweight
FallbackClassLoader.
This should not incur any slowdowns, does not require filtering, etc.
Regarding your suggestion concerning Codecs.reload, etc.: I would definitely
not want to have these rather-internal calls in the application code. So
providing an Util class that hides the SPI details would be essential.
Practically, what you describe may boil down to a static Lucene bootstrap
method, e.g. a "Lucene.init()". I am not really sure if this is a good idea,
especially if the only benefit is that we abide by the SPI spec to the very
last word.
was (Author: [email protected]):
Revised patch.
Now uses Thread#getContextClassLoader and falls back to the default ClassLoader.
> 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: LUCENE-4713.patch, 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]
