[ https://issues.apache.org/jira/browse/SOLR-5746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=0&r1=1612433&r2=1612432&pathrev=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="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