Thanks for your answers.
I've made some test, the singleton is correctly shared between handlers
in the same core, but not between cores, while putting connection pool
jar (and its dependencies) inside the war, make it works as it should
(but that doesn't look like a solution to me).
It seems to me that this behavior is perfectly in line with what
discussed in this thread.

In my opinion, Henrib's approach (one "shared" lib, and one "private"
lib for each core) would meet my needs, and also allow that "separation"
between cores, you are aiming at; this way it would be up to the users
to choose how to deal with multiple cores, according to their needs, and
the limitations an approach could carry compared to the other.

Thanks,
Walter

Henrib wrote:
> 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.
>
>
>   

Reply via email to