[ 
https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-5746.
----------------------------

       Resolution: Fixed
    Fix Version/s: 4.10
                   5.0
         Assignee: Hoss Man

Thanks again for your patch Maciej!

> 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
>            Assignee: Hoss Man
>             Fix For: 5.0, 4.10
>
>         Attachments: SOLR-5746.patch, SOLR-5746.patch, SOLR-5746.patch, 
> SOLR-5746.patch, SOLR-5746.patch
>
>
> 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.2#6252)

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

Reply via email to