[
https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904881#comment-13904881
]
Hoss Man commented on SOLR-5746:
--------------------------------
I think what we should do is...
* change the parsing logic to be more like solrconfig.xml and build a NamedList
for each section of solr.xml
** convert each NamedList to SolrParams when possible for easy value type
checkig & conversion (i think this would work for each section in solr.xml
today - but some future sections might need to be more complicated)
* remove each known config option from the params
* error if any unexpected values are found in the config, so typos in config
option names aren't silently ignored.
> solr.xml parsing of "str" vs "int" vs "bool" is brittle; fails silently;
> expects odd type for "shareSchema"
> --------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-5746
> URL: https://issues.apache.org/jira/browse/SOLR-5746
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.3, 4.4, 4.5, 4.6
> Reporter: Hoss Man
>
> A comment in the ref guide got me looking at ConfigSolrXml.java and noticing
> that the parsing of solr.xml options here is very brittle and confusing. In
> particular:
> * if a boolean option "foo" is expected along the lines of {{<bool
> name="foo">true</bool>}} it will silently ignore {{<str
> name="foo">true</str>}}
> * likewise for an int option {{<int name="bar">32</int>}} vs {{<str
> name="bar">32</str>}}
> ... this is inconsistent with the way solrconfig.xml is parsed. In
> solrconfig.xml, the xml nodes are parsed into a NamedList, and the above
> options will work in either form, but an invalid value such as {{<bool
> name="foo">NOT A BOOLEAN</bool>}} will generate an error earlier (when
> parsing config) then {{<str name="foo">NOT A BOOLEAN</str>}} (attempt to
> parse the string as a bool the first time the config value is needed)
> In addition, i notice this really confusing line...
> {code}
> propMap.put(CfgProp.SOLR_SHARESCHEMA,
> doSub("solr/str[@name='shareSchema']"));
> {code}
> "shareSchema" is used internally as a boolean option, but as written the
> parsing code will ignore it unless the user explicitly configures it as a
> {{<str/>}}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]