[
https://issues.apache.org/jira/browse/SOLR-4652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616802#comment-13616802
]
Uwe Schindler edited comment on SOLR-4652 at 3/28/13 11:21 PM:
---------------------------------------------------------------
Hi Ryan,
thanks for bringing this up, you made my day! I was also disappointed when I
was digging into that several times, last time when working on Lucene's SPI
issues.
In my opinion, the context classloader should be out of scope (in general, code
that uses the context class loader as a "default" because no other classloader
is there is buggy to me and may drive crazy under certain circumstances like
different per-thread behaviour, e.g. in callbacks called from system threads).
The ResourceLoaders/Classloaders in Solr should be built on startup of the
webapplication and should use the webapp classloader as root (and dont use
context class loader as replacement for webapp classloader, just get it e.g.
from inside the SolrDispatchFilter's init method like
this.getClass().getClassLoader()). Any classloader created from solr should be
a child/grandchild of this root class loader. The core container's resource
loader should be the only child of the webapp classloader. Every solr core then
should be a child of the core container's classloader. Also those resource
loaders must use parent-first semantics as Java suggests (in that case its
unlikely that you get class cannot be cast to same name...).
I simply had no time to fix this, but I may be able to help. A correct
classloader design is hard, but doable - and your issue confirms my problems
with the current design.
was (Author: thetaphi):
Hi Ryan,
thanks for bringing this up, you made my day! I was also disappointed when I
was digging into that several times, last time when working on Lucene's SPI
issues.
In my opinion, the context classloader should be out of scope (in general, code
that uses the context class loader as a "default" because no other classloader
is there is buggy to me and may drive crazy under certain circumstances like
different per-thread behaviour, e.g. in callbacks called from system threads).
The ResourceLoaders/Classloaders in Solr should be built on startup of the
webapplication and should use the webapp classloader as root (and dont use
context class loader as replacement for webapp classloader, just get it e.g.
from inside the SolrDispatchFilter's init method like
this.getClass().getClassLoader()). Any classloader created from solr should use
this root class loader. The core container's resource loader should be the only
child of the webapp classloader. Every solr core then should be a child of the
core container's classloader. Also those resource loaders must use parent-first
semantics as Java suggests (in that case its unlikely that you get class cannot
be cast to same name...).
I simply had no time to fix this, but I may be able to help. A correct
classloader design is hard, but doable - and your issue confirms my problems
with the current design.
> 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.
> 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.
--
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]
