[ https://issues.apache.org/jira/browse/LUCENE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604976#comment-13604976 ]
Uwe Schindler commented on LUCENE-4713: --------------------------------------- As Lucene 4.2.1 is coming, I backported to 4.2 branch in revision: 1457695 > 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: 5.0, 4.3, 4.2.1 > > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org