: I don't know if this applies in your case but there is now one class loader : per solr core instance (more exactly per config; it used to be a static : before).
: If your connection pool is a static member of a core handler, each core will : create the handler through different class loaders - thus different : instances of the static member. i didn't understand the orriginal issue, but based on Ryan's reply I think Henrib is right on the money. : Internally, it could be better (aka easier to use) to create one class : loader per instance dir instead of per core. perhaps. it depends largely on what the long term goals of multi-core support are ... if we're striving for "dynamicly" creating "solr contexts" independently of "servlet contexts" then the current behavior is probably ideal ... we're protecting the plugins of each SolrCore from corrupting eachother. if however we want SolrCores to be able to "communicate" and interact with eachother ... well, then a class loader per solr webapp mmight make sense. honestly: i'm not sure i understand what "instance dir" means in a multi-core world ... do all cores share an instance dir? how do configs and dataDirs work in that case? -Hoss
