[
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: [email protected]
For additional commands, e-mail: [email protected]
