[jira] [Commented] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails

["Christian Kohlschütter (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566884#comment-13566884 ] 

Christian Kohlschütter commented on LUCENE-4713:
------------------------------------------------

Uwe,

I have tried your suggested workaround. Unfortunately it does not work.

The Codec class has a static field that already requires a working SPI setup:
{quote}
private static Codec defaultCodec = Codec.forName("Lucene41");
{quote}

Calling Codec.reloadCodecs with my ClassLoader will use the Thread-context ClassLoader (via Codec#loader) and thus fails with
{quote}
java.lang.IllegalArgumentException: A SPI class of type org.apache.lucene.codecs.Codec with name 'Lucene40' does not exist. You need to add the corresponding JAR file supporting this SPI to your classpath.The current classpath supports the following names: []
	at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:104)
	at org.apache.lucene.codecs.Codec.forName(Codec.java:95)
	at org.apache.lucene.codecs.Codec.<clinit>(Codec.java:122)
	... 28 more
{quote}
(stack trace from Lucene 4.0, still valid for 4.1).

I could resolve this by moving Codec.forName into Codec#getDefault:

{quote}
{noformat}
private static Codec defaultCodec = null;
  
  /** expert: returns the default codec used for newly created
   *  {@link IndexWriterConfig}s.
   */
  // TODO: should we use this, or maybe a system property is better?
  public static Codec getDefault() {
    if(defaultCodec == null) {
      defaultCodec = Codec.forName("Lucene40");      
    }
    return defaultCodec;
  }
{noformat}
{quote}

Moreover, it is important to call PostingsFormat#reloadPostingsFormats before Codec#reloadCodecs, because the Lucene40 codec looks up the PostingFormat class...

As you can see, fixing this easily becomes a mess -- we would have to find a specific order of what to load first. Finally, in the case of {{AnalysisSPILoader}} there is no static method to call...

I am pretty sure that it is safer to use the fall-back ClassLoader I provided in the patch.

                
> 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
>            Priority: Minor
>              Labels: ClassLoader, Thread
>         Attachments: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org