Classloading in SharedLib vs WAR

[Jan Høydahl <ja...@cominvent.com>]

Hi,

It is quite natural to package a custom Solr component as a jar file for inclusion in sharedLib or instanceDir/lib. However, that will not always work because of different class loaders, and classes in same package must be loaded by same loader to work.

One example is the excellent hon-lucene-synonyms QParser at which extends edismax and adds multiword synonym support. However, as noted in step 4 in this guide https://github.com/healthonnet/hon-lucene-synonyms#step-4 it won't work to add it as a jar in sharedLib due to classloading issues, so you have to repackage the WAR and place it in WEB-INF/lib.

How can we improve the pluggability of Solr, so people can write 3rd party jars and easily plug it in to an exsiting Solr without repackaging war?

First ting that comes to mind is to rearchitecture our ResourceLoader as a singleton which sees everything.
Another workaround would be to produce a war without any jars in WEB-INF/lib and place those in a separate lib folder, which would be loaded by the same classLoader as sharedLib.

Ideas?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Classloading in SharedLib vs WAR

[Robert Muir <rc...@gmail.com>]

On Wed, May 29, 2013 at 5:33 AM, Jan Høydahl <ja...@cominvent.com> wrote:

> One example is the excellent hon-lucene-synonyms QParser at which extends
> edismax and adds multiword synonym support. However, as noted in step 4 in
> this guide https://github.com/healthonnet/hon-lucene-synonyms#step-4 it
> won't work to add it as a jar in sharedLib due to classloading issues, so
> you have to repackage the WAR and place it in WEB-INF/lib.
>
> How can we improve the pluggability of Solr, so people can write 3rd party
> jars and easily plug it in to an exsiting Solr without repackaging war?
>
> First ting that comes to mind is to rearchitecture our ResourceLoader as a
> singleton which sees everything.
> Another workaround would be to produce a war without any jars in
> WEB-INF/lib and place those in a separate lib folder, which would be loaded
> by the same classLoader as sharedLib.
>

First that that comes to mind is to upgrade to a recent version.