[
https://issues.apache.org/jira/browse/SOLR-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705742#comment-13705742
]
Alan Woodward commented on SOLR-5028:
-------------------------------------
TBH, it would be nicest to just remove cfg.get() entirely, and make ConfigSolr
a proper POJO. But that's another issue.
This is still not ideal, as I've just noticed that my quick-n-dirty patch still
assumes a single-level plugin info hierarchy and won't deal with <arr> or <lst>
values properly. Will try and fix that.
> Incorrect ShardHandlerFactory creation
> --------------------------------------
>
> Key: SOLR-5028
> URL: https://issues.apache.org/jira/browse/SOLR-5028
> Project: Solr
> Issue Type: Bug
> Affects Versions: 5.0, 4.4
> Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-5028.patch, SOLR-5028.patch, SOLR-5082.patch
>
>
> It seems to me that there are two bugs in the ShardHandlerFactoryCreation
> that cancel each other and it seems to be working with the old style
> solr.xml, but not with the "new style". ConfigSolrOldXml seems to be
> expecting the shardHandlerFactory with the xpath:
> solr/shardHandlerFactory/@class
> Instead of solr/*cores*/shardHandlerFactory/@class as it used to be. This is
> never caught because in the CoreContainer the ShardHandlerFactory is
> initialized using
> "configSolr.getConfig().getNode("solr/cores/shardHandlerFactory", false);"
> instead of "configSolr.get(CfgProp.SOLR_SHARDHANDLERFACTORY_CLASS, null);" or
> something like that. However, if you use the "new style" xml, the
> CoreContainer will still try to initialize the factory like that, and won't
> find the SHF.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
