Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-5746

solr.xml parsing of "str" vs "int" vs "bool" is brittle; fails silently; expects odd type for "shareSchema"



    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.3, 4.4, 4.5, 4.6
    • Fix Version/s: 4.10, 6.0
    • Component/s: None
    • Labels:


      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...

          propMap.put(CfgProp.SOLR_SHARESCHEMA, doSub("solr/str[@name='shareSchema']"));

      "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/>


        1. SOLR-5746.patch
          36 kB
          Maciej Zasada
        2. SOLR-5746.patch
          44 kB
          Maciej Zasada
        3. SOLR-5746.patch
          47 kB
          Maciej Zasada
        4. SOLR-5746.patch
          50 kB
          Maciej Zasada
        5. SOLR-5746.patch
          50 kB
          Chris M. Hostetter



            • Assignee:
              hossman Chris M. Hostetter
              hossman Chris M. Hostetter
            • Votes:
              0 Vote for this issue
              4 Start watching this issue


              • Created: