[
https://issues.apache.org/jira/browse/SOLR-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2983:
---------------------------
Priority: Critical (was: Major)
Fix Version/s: 4.0
3.6
this seems like a really silly and anoying mistake in 3.5 ... we clearly need
better tests using mock MergePolicies.
herbert: do you have a patch to fix the init code?
> Unable to load custom MergePolicy
> ---------------------------------
>
> Key: SOLR-2983
> URL: https://issues.apache.org/jira/browse/SOLR-2983
> Project: Solr
> Issue Type: Bug
> Reporter: Mathias Herberts
> Priority: Critical
> Fix For: 3.6, 4.0
>
>
> As part of a recent upgrade to Solr 3.5.0 we encountered an error related to
> our use of LinkedIn's ZoieMergePolicy.
> It seems the code that loads a custom MergePolicy was at some point moved
> into SolrIndexConfig.java from SolrIndexWriter.java, but as this code was
> copied verbatim it now contains a bug:
> try {
> policy = (MergePolicy)
> schema.getResourceLoader().newInstance(mpClassName, null, new
> Class[]{IndexWriter.class}, new Object[]{this});
> } catch (Exception e) {
> policy = (MergePolicy)
> schema.getResourceLoader().newInstance(mpClassName);
> }
> 'this' is no longer an IndexWriter but a SolrIndexConfig, therefore the call
> to newInstance will always throw an exception and the catch clause will be
> executed. If the custom MergePolicy does not have a default constructor
> (which is the case of ZoieMergePolicy), the second attempt to create the
> MergePolicy will also fail and Solr won't start.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
