You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Maciej Zasada (JIRA)" <ji...@apache.org> on 2014/07/15 13:09:05 UTC
[jira] [Comment Edited] (SOLR-5746) solr.xml parsing of "str" vs
"int" vs "bool" is brittle; fails silently; expects odd type for
"shareSchema"
[ https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060685#comment-14060685 ]
Maciej Zasada edited comment on SOLR-5746 at 7/15/14 11:08 AM:
---------------------------------------------------------------
Hi [~hossman],
I've attached updated patch file:
* removed {{DOMUtil.readNamedChildrenAsNamedList}} method and used (slightly modified) existing API of {{DOMUtil}} instead.
* removed reading values from {{SolrParam}} - they are being read directly from the {{NamedList<>}}
* added reporting of duplicated config options ({{DEBUG}} level) per parent node, as well as exception message containing list of duplicated parameters, e.g.
{code}<solr>
<solrcloud>
<int name="int-param">1</int>
<str name="str-param">STRING-1</str>
…
<int name="int-param">2</int>
<str name="str-param">STRING-2</str>
</solrcloud>
</solr>
{code}
will cause an exception:
{code}
Duplicated 2 config parameter(s) in solr.xml file: [int-param, str-param]
{code}
However, if parameters with a same name are attached to different parent nodes everything will pass just fine, e.g.
{code}<solr>
<solrcloud>
<int name="int-param">1</int>
<str name="str-param">STRING-1</str>
…
</solrcloud>
<logging>
…
<int name="int-param">2</int>
<str name="str-param">STRING-2</str>
</logging>
</solr>
{code}
In this case no exception will be thrown.
Some examples to sum it up:
|{{solr.xml}} file fragment|Expected type|Parsing result|
|{{<int name="hostPort">44</int>}}|{{Integer}}|(/)
|{{<str name="hostPort">44</str>}}|{{Integer}}|(/)
|{{<long name="hostPort">44</long>}}|{{Integer}}|(x)
|{{<bool name="hostPort">44</bool>}}|{{Integer}}|(x)
|{{<float name="hostPort">44</float>}}|{{Integer}}|(x)
|{{<double name="hostPort">44</double>}}|{{Integer}}|(x)
|{{<int name="enabled">true</int>}}|{{Boolean}}|(x)
|{{<str name="enabled">true</str>}}|{{Boolean}}|(/)
|{{<long name="enabled">true</long>}}|{{Boolean}}|(x)
|{{<bool name="enabled">true</bool>}}|{{Boolean}}|(/)
|{{<float name="enabled">true</float>}}|{{Boolean}}|(x)
|{{<double name="enabled">true</double>}}|{{Boolean}}|(x)
{{ant clean test}} shows that there's no regression.
[~jkrupan] this change clearly is not backward compatible with the existing {{solr.xml}} files. For instance - unknown config values won't be silently ignored - an exception will be thrown instead. However, I didn't realise that {{solr.xml}} files are versioned the same way as {{schema.xml}} files are. Should I bump the schema version to 1.6?
Cheers,
Maciej
was (Author: maciej.zasada):
Hi [~hossman],
I've attached updated patch file:
* removed {{DOMUtil.readNamedChildrenAsNamedList}} method and used (slightly modified) existing API of {{DOMUtil}} instead.
* removed reading values from {{SolrParam}} - they are being read directly from the {{NamedList<>}}
* added reporting of duplicated config options ({{DEBUG}} level) per parent node, as well as exception message containing list of duplicated parameters, e.g.
{code}<solr>
<solrcloud>
<int name="int-param">1</int>
<str name="str-param">STRING-1</str>
…
<int name="int-param">2</int>
<str name="str-param">STRING-2</str>
</solrcloud>
</solr>
{code}
will cause an exception:
{code}
Duplicated 2 config parameter(s) in solr.xml file: [int-param, str-param]
{code}
However, if parameters with a same name are attached to different parent nodes everything will pass just fine, e.g.
{code}<solr>
<solrcloud>
<int name="int-param">1</int>
<str name="str-param">STRING-1</str>
…
</solrcloud>
<logging>
…
<int name="int-param">2</int>
<str name="str-param">STRING-2</str>
</logging>
</solr>
{code}
In this case no exception will be thrown.
Some examples to sum it up:
|{{solr.xml}} file fragment|Expected type|Parsing result|
|{{<int name="hostPort">44</int>}}|{{Integer}}|(/)
|{{<str name="hostPort">44</str>}}|{{Integer}}|(/)
|{{<long name="hostPort">44</long>}}|{{Integer}}|(/)
|{{<bool name="hostPort">44</bool>}}|{{Integer}}|(x)
|{{<float name="hostPort">44</float>}}|{{Integer}}|(x)
|{{<double name="hostPort">44</double>}}|{{Integer}}|(x)
|{{<int name="enabled">true</int>}}|{{Boolean}}|(x)
|{{<str name="enabled">true</str>}}|{{Boolean}}|(/)
|{{<long name="enabled">true</long>}}|{{Boolean}}|(x)
|{{<bool name="enabled">true</bool>}}|{{Boolean}}|(/)
|{{<float name="enabled">true</float>}}|{{Boolean}}|(x)
|{{<double name="enabled">true</double>}}|{{Boolean}}|(x)
{{ant clean test}} shows that there's no regression.
[~jkrupan] this change clearly is not backward compatible with the existing {{solr.xml}} files. For instance - unknown config values won't be silently ignored - an exception will be thrown instead. However, I didn't realise that {{solr.xml}} files are versioned the same way as {{schema.xml}} files are. Should I bump the schema version to 1.6?
Cheers,
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
> Attachments: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org