You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Christian Kohlschütter (JIRA)" <ji...@apache.org> on 2013/01/24 08:33:22 UTC
[jira] [Comment Edited] (LUCENE-4713) Replace calls to
Thread#getContextClassLoader with the ClassLoader of the current class
[ 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: ck@newsclub.de):
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org