Solr
  1. Solr
  2. SOLR-92

XML parsing error with resin-3.0.21

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: None
    • Labels:
      None
    • Environment:

      running resin-3.0.21

      Description

      When the resin XML parser starts, it gets the following error trying to parse the config file:

      [00:25:35.025] Caused by: java.lang.NumberFormatException: empty String
      [00:25:35.025] at
      sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:994)
      [00:25:35.025] at java.lang.Float.parseFloat(Float.java:394)
      [00:25:35.025] at org.apache.solr.core.Config.getFloat(Config.java:174)
      [00:25:35.025] at
      org.apache.solr.schema.IndexSchema.readConfig(IndexSchema.java:273)

      see: http://www.mail-archive.com/solr-dev@lucene.apache.org/msg01852.html

      1. resinXmlParser.patch
        0.8 kB
        Ryan McKinley

        Activity

        Hide
        Ryan McKinley added a comment -

        simple change moving:
        case Node.ATTRIBUTE_NODE:

        to use:
        nd.getNodeValue()

        Show
        Ryan McKinley added a comment - simple change moving: case Node.ATTRIBUTE_NODE: to use: nd.getNodeValue()
        Hide
        Yonik Seeley added a comment -

        Thanks Ryan, do we know if this still works with much older resin releases (that the previous patch was supposed to fix)?

        Show
        Yonik Seeley added a comment - Thanks Ryan, do we know if this still works with much older resin releases (that the previous patch was supposed to fix)?
        Hide
        Ryan McKinley added a comment -

        I just tried it with resin-2.1.17 (2005/12/22) and it appears to work fine. I have not tried it with tomcat. It works with jetty as the tests are run with that correct?

        Show
        Ryan McKinley added a comment - I just tried it with resin-2.1.17 (2005/12/22) and it appears to work fine. I have not tried it with tomcat. It works with jetty as the tests are run with that correct?
        Hide
        Yonik Seeley added a comment -

        I just briefly tried Tomcat 5.5.20, Jetty 5.1, Jetty 6.1rc2 and they all seem to be OK with this change (very brief test... start up, run a single query)

        Show
        Yonik Seeley added a comment - I just briefly tried Tomcat 5.5.20, Jetty 5.1, Jetty 6.1rc2 and they all seem to be OK with this change (very brief test... start up, run a single query)
        Hide
        Hoss Man added a comment -

        should have put this in the bug instead of email...

        http://www.nabble.com/Schema-Parsing-Failed%2C-fix--tf2868892.html#a8038207


        : : Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it
        : : works for resin and the tests pass.
        :
        : Hmmm... yeah, this seems to be a mistake in the DOM-Level-3-Core
        : description of what getText is suppose to do ... it says that for
        : ATTRIBUTE_NODE you should concat all of the children – but how would an
        : ATTRIBUTE ever have children?

        Did some more reading ... according to DOM-Level-3-Core, an Attr's allowed
        children are "Text" and "EntityReference".

        Xerces2-j NodeImpl..getTextContent duplicates the table from the
        Level-3-Core docs (which is also in the java 1.5 javadocs for
        org.w3c.dom.Node.getTextContent()) which the notable exception that they
        move ATTRIBUTE_NODE down into the second row (indicating nodeValue should
        be used instead of concating the children) ... the impl backs this up
        (AttrImpl inherits getTextContent from NodeImpl, which by default returns
        this.getNodeValue())

        http://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/dom/NodeImpl.html#getTextContent()
        http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getTextContent()
        http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/AttrImpl.java?view=markup
        http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/NodeImpl.java?view=markup

        Fortunately, the DOM Spec says that accessing the Attr.nodeValue is
        defined to be Attr.value, which is documented as...

        On retrieval, the value of the attribute is returned as a string.
        Character and general entity references are replaced with their values.

        ...so even if someone out there is acctually obeying the spec about
        giving Attr's child nodes, we should still be safe using getNodeValue in
        the Node.ATTRIBUTE_NODE case since the spec says that needs to work too.

        ------

        ...i'll commit this change along with some more comments explaining it

        Show
        Hoss Man added a comment - should have put this in the bug instead of email... http://www.nabble.com/Schema-Parsing-Failed%2C-fix--tf2868892.html#a8038207 : : Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it : : works for resin and the tests pass. : : Hmmm... yeah, this seems to be a mistake in the DOM-Level-3-Core : description of what getText is suppose to do ... it says that for : ATTRIBUTE_NODE you should concat all of the children – but how would an : ATTRIBUTE ever have children? Did some more reading ... according to DOM-Level-3-Core, an Attr's allowed children are "Text" and "EntityReference". Xerces2-j NodeImpl..getTextContent duplicates the table from the Level-3-Core docs (which is also in the java 1.5 javadocs for org.w3c.dom.Node.getTextContent()) which the notable exception that they move ATTRIBUTE_NODE down into the second row (indicating nodeValue should be used instead of concating the children) ... the impl backs this up (AttrImpl inherits getTextContent from NodeImpl, which by default returns this.getNodeValue()) http://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/dom/NodeImpl.html#getTextContent( ) http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getTextContent( ) http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/AttrImpl.java?view=markup http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/NodeImpl.java?view=markup Fortunately, the DOM Spec says that accessing the Attr.nodeValue is defined to be Attr.value, which is documented as... On retrieval, the value of the attribute is returned as a string. Character and general entity references are replaced with their values. ...so even if someone out there is acctually obeying the spec about giving Attr's child nodes, we should still be safe using getNodeValue in the Node.ATTRIBUTE_NODE case since the spec says that needs to work too. ------ ...i'll commit this change along with some more comments explaining it
        Hide
        Hoss Man added a comment -

        Hmmm... forgot to resolve this, changes commited back in december.

        Show
        Hoss Man added a comment - Hmmm... forgot to resolve this, changes commited back in december.
        Hide
        Hoss Man added a comment -

        This bug was modified as part of a bulk update using the criteria...

        • Marked ("Resolved" or "Closed") and "Fixed"
        • Had no "Fix Version" versions
        • Was listed in the CHANGES.txt for 1.2

        The Fix Version for all 39 issues found was set to 1.2, email notification
        was suppressed to prevent excessive email.

        For a list of all the issues modified, search jira comments for this
        (hopefully) unique string: 20080415hossman2

        Show
        Hoss Man added a comment - This bug was modified as part of a bulk update using the criteria... Marked ("Resolved" or "Closed") and "Fixed" Had no "Fix Version" versions Was listed in the CHANGES.txt for 1.2 The Fix Version for all 39 issues found was set to 1.2, email notification was suppressed to prevent excessive email. For a list of all the issues modified, search jira comments for this (hopefully) unique string: 20080415hossman2

          People

          • Assignee:
            Hoss Man
            Reporter:
            Ryan McKinley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development