It seems to me multicore should avoid replicating (or restricting itself to) features what we can get with multiple web apps; I advocate allowing tighter couplings between cores in the former which seems to me closer to user expectations (at least Walter's). If we keep one class loader per core instance, sharing objects is as 'hard' with multiple cores as it is with multiple web apps.
If we were to create class loaders not per instance but per 'lib' directory (not per instance dir as I mentioned earlier but per library directory), this would allow keeping the choice (make different lib directories for classes/instances you dont want to share, share one otherwise). In essence, this makes a shareable context named by library dir and implemented through class loaders. Or could have a 'shared' library dir in the solr installation - and a dedicated class loader (parent-first resolution...). And since we are also looking at ways to post-init some dynamically created objects with a core (solr-399), there will be soon new ways to inject per core behavior in shared objects - keeping them segregated if needed being one. I believe we can keep core strict independence *and* add sharing core functionality allowing a wider choice to answer users needs. -- View this message in context: http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html#a13690225 Sent from the Solr - Dev mailing list archive at Nabble.com.
