[jira] [Commented] (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-tabpanelfocusedCommentId=14069345#comment-14069345
]
Hoss Man commented on SOLR-5746:
bq. My only review comment would be to prefer using hamcrest assertThat()
functions in tests, rather than assertTrue(), just because you get nicer error
messages when they fail. ...
the assertTrue's actually do have messages on them, and they are actual value
asserts that just happen to be true -- but i'll change them to assertEquals so
it's more obvious what's happening if/when they fail.
going to commit as soon as my updated to trunk started running all tests
passes again.
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14069422#comment-14069422
]
ASF subversion and git services commented on SOLR-5746:
---
Commit 1612419 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1612419 ]
SOLR-5746: Bugs in solr.xml parsing have been fixed to more correctly deal with
the various datatypes of options people can specify, additional error handling
of duplicated/unidentified options has also been added
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14069519#comment-14069519
]
ASF subversion and git services commented on SOLR-5746:
---
Commit 1612433 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612433 ]
SOLR-5746: Bugs in solr.xml parsing have been fixed to more correctly deal with
the various datatypes of options people can specify, additional error handling
of duplicated/unidentified options has also been added (merge r1612419)
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14069524#comment-14069524
]
Hoss Man commented on SOLR-5746:
bq. ...the assertTrue's actually do have messages on them...
correction: the messages in the patch were all the same, but in my local copy
before committing i had fixed them all to be clear about which config prop
wasn't coming up as expected.
This is now on trunk backported to 4x -- one hitch that came up in the
backporting was that 4x still supports the notion of an implicit solr.xml file
(if you aren't in cloud mode) so i had to manually massage the backport to
ConfigSolr.java
[~romseygeek]: if you could spot check the 4x changes to ensure i didn't botch
something that would be appreciated:
https://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/core/src/java/org/apache/solr/core/ConfigSolr.java?limit_changes=0r1=1612433r2=1612432pathrev=1612433
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14063425#comment-14063425
]
Maciej Zasada commented on SOLR-5746:
-
Hi [~hossman],
thanks for the code review and all your suggestions. I'll keep them in mind for
the future work. Revised patch looks good to me.
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14063623#comment-14063623
]
Alan Woodward commented on SOLR-5746:
-
+1, some nice cleanups here.
My only review comment would be to prefer using hamcrest assertThat() functions
in tests, rather than assertTrue(), just because you get nicer error messages
when they fail. But that's a pretty nitty nit to pick.
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, 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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14059771#comment-14059771
]
Maciej Zasada commented on SOLR-5746:
-
bq. 1) can you explain why the need for the new
DOMUtil.readNamedChildrenAsNamedList method that you added instead of just
using the existing DOMUtil.childNodesToNamedList
The reason why I didn’t use {{DOMUtil.childNodesToNamedList}} is that I wanted
to move the type conversion from reading the DOM to the point, when I knew what
type exactly should be used. If I used that method, all values would be
upcasted to {{Object}}, and I would have to do the type checking to make sure
if the type is correct, something like
{code}
if (value instanceof Integer) {
type is ok, just store the value as it is
} else if(value instanceof String) {
type is not ok, but let's try parsing this String to something useful
}
{code} Instead, I’m storing only the raw values, and trying to imply the
correct type only once, without the type checking. But when I’m thinking it all
over again your approach seems to have a significant advantage - in proposed
implementation type mismatch would be permitted for all types, not only
{{str/str}}, e.g. {{bool3.14/bool}} would be perfectly valid config
option, if {{double}} type was expected. You’re right, I’ll remove new method
and use {{DOMUtil.childNodesToNamedList}}.
bq. 2) Speaking of which: what's the purpose exactly of configAsSolrParams if
the original NamedList is still being passed to the storeConfigPropertyAs*
methods - why not just get the values directly from there?
Since I stored raw config values, I used {{SolrParam}} to do the type
conversion, but I didn’t find any API for a parameter removal. That’s why I’m
keeping the original NamedList, so that I can remove correctly read values and
keep track of the unknown ones.
bq. 3) One piece of validation that i believe is still missing here is to throw
an errir if/when a config value is specified multiple times
I should’ve thought about that, good catch! I’ll add detection of such errors.
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
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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14059805#comment-14059805
]
Jack Krupansky commented on SOLR-5746:
--
Will the changes for this issue result in a bump of the Solr schema version (to
1.6), so that if existing apps do happen to work (albeit maybe incorrectly)
with the current version 1.5 schema processing, they will still work in Solr
4.10 (or whenever this ships)? I hope so.
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
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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14059550#comment-14059550
]
Hoss Man commented on SOLR-5746:
Hi Maciej,
I glance over the patch a bit more today:
1) can you explain why the need for the new
{{DOMUtil.readNamedChildrenAsNamedList}} method that you added instead of just
using the existing {{DOMUtil.childNodesToNamedList}} (which delegates to
{{addToNamedList}} and immediately validates that element text conforms to the
stated type).
I realize that using {{DOMUtil.childNodesToNamedList}} won't magically help
parse/validate the config options in the backcompat cases like {{str
name=shareSchematrue/str}} -- but that's where things like your
{{storeConfigPropertyAsInt}} and {{storeConfigPropertyAsBoolean}} can be in
charge of doing the cast if the raw value is still a string.
(i want to make sure we aren't introducing a redundant method in {{DOMUtil}}.
2) Speaking of which: what's the purpose exactly of configAsSolrParams if the
original NamedList is still being passed to the {{storeConfigPropertyAs*}}
methods - why not just get the values directly from there?
3) One piece of validation that i believe is still missing here is to throw an
errir if/when a config value is specified multiple times -- I i remember the
behavior of NamedList correctly, i think the way you have things now it will
silently just use the first one, and then remove both. We should definitely
have an error check that any of these single valued config options is in fact
only specified once in the NamedList -- so people don't try to add a setting
they've read about in the docs w/o realizing it's already defined higher up in
the file (we've seen that happen with settings in solrconfig.xml many times
between we locked that down and made it an error case)
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
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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=14057675#comment-14057675
]
Hoss Man commented on SOLR-5746:
Maciej:
At first glance this looks awsome -- i'll try to review it more closely in the
next few days.
A few quick things i noticed:
* can you update your tests to use the frameworks randomization when picking
the boolean/numeric values that you put into the config strings -- instead of
using hardcoded values? that way we reduce the risk of false positives due to
the code using defaults instead of the value you intended (even if the defaults
change)
* can you add some asserts regarding the error message included in the
SolrExceptions that are caught by the tests, so we verify that the user is
getting a useful message?
* in the case where there might be multiple unexpected config keys found, can
you add logging of each of the unexpected keys, and then make the exception
thrown something like Found 5 unexpected config options in solr.xml: foo, bar,
baz, yak, zot
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
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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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
[jira] [Commented] (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-tabpanelfocusedCommentId=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=footrue/bool}} it will silently ignore {{str
name=footrue/str}}
* likewise for an int option {{int name=bar32/int}} vs {{str
name=bar32/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=fooNOT A BOOLEAN/bool}} will generate an error earlier (when
parsing config) then {{str name=fooNOT 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
