lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Ernst (JIRA)" <>
Subject [jira] [Updated] (SOLR-4652) Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
Date Sun, 31 Mar 2013 03:59:16 GMT


Ryan Ernst updated SOLR-4652:

    Attachment: SOLR-4652.patch

This patch makes core resource loaders use the CoreContainer.loader.getClassLoader() as it's
parent (solves issue #1) and adds sharedLib to CoreContainer.loader's class loader before
initializing the shard handler factory (solves issue #2).

I would like to add a unit test to ensure this isn't broken by any future refactoring here.
 Any thoughts on where, or how (since most tests seem to bypass this initialization for core
container) I should add a test?
> Resource loader has broken behavior for solr.xml plugins (basically ShardHandlerFactory)
> ----------------------------------------------------------------------------------------
>                 Key: SOLR-4652
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Ryan Ernst
>         Attachments: SOLR-4652.patch
> I have the following scenario:
> MyShardHandlerFactory is plugged in via solr.xml.  The jar containing MyShardHandlerFactory
is in the shared lib dir.  There are a couple issues:
> 1. From within a per core handler (that is loaded within the core's lib dir), you grab
the ShardHandlerFactory from CoreContainer, casting to MyShardHandlerFactory will results
in a ClassCastException with a message like "cannot cast instance of MyShardHandlerFactory
to MyShardHandlerFactory".
> 2. Adding a custom dir for shared lib (for example "mylib") does not work.  The ShardHandlerFactory
is initialized before sharedLib is loaded.
> I've been pouring through the code on this and I don't see an easy fix.  I'll keep looking
at it, but I wanted to get this up so hopefully others have some thoughts on how best to fix.
 IMO, it seems like there needs to be a clear chain of resource loaders (one for loading solr.xml,
a child for loading the lib dir, used for solr.xml plugins, a grandchild for per core config,
and a great grandchild for per core lib dir based plugins).  Right now there are some siblings,
because any place a SolrResourceLoader is created with a null parent classloader, it gets
the jetty thread's classloader as the parent.

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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message