[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Ernst updated SOLR-4652:
-----------------------------
Description:
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.
was:
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.
3. I believe there is another problem with the chaining, in that if you
specified a sharedLib with the same name as the default, then you get one
classloader that is used to instantiate, but then if you try to instantiate an
instance of that class from within core specific code, like a handler, you will
get the intermediate sharedLib based class loader to load a different version
(libLoader in CoreContainer).
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.
> Resource loader has broken behavior for solr.xml plugins (basically
> ShardHandlerFactory)
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-4652
> URL: https://issues.apache.org/jira/browse/SOLR-4652
> Project: Solr
> Issue Type: Bug
> Reporter: Ryan Ernst
>
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
