Solr
  1. Solr
  2. SOLR-899

NullPointerException in ClientUtils.writeXML on NULL field value

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Not A Problem
    • Affects Version/s: 1.3
    • Fix Version/s: None
    • Component/s: clients - java
    • Labels:
      None

      Description

      This exception occurs if I have a field in a document with a null value.

      java.lang.NullPointerException
      at org.apache.solr.client.solrj.util.ClientUtils.writeXML(ClientUtils.java:117)
      at org.apache.solr.client.solrj.request.UpdateRequest.getXML(UpdateRequest.java:169)
      at org.apache.solr.client.solrj.request.UpdateRequest.getContentStreams(UpdateRequest.java:160)
      ...

      Previous versions of this class had a null check, which was subsequently removed. I have no problem with removing the previous null-check, as it seemed to "hide" a programming mistake (i.e. null values). However, I think that the exception that occurs here could at least be a bit more informative. Performing a null check and then throwing some sort of RuntimeException or IOException with a descriptive message would be very helpful. Such as "Failure, NULL value for field named[foo] detected".

      Alternatively, I think that an argument could be made that this NULL shouldn't have been allowed in the document in the first place. If that is the case, then NULL checks with similarly helpful messages could be performed upstream of this issue. I personally lean this way, as I prefer to find a programming mistake closer to the source of the issue. It allows me to find out exactly where the NULL was inserted in the first place.

        Activity

        Hide
        Sami Siren added a comment -

        This does not seem to be a problem with trunk version of solrj: I can add fields with null values and they are silently being ignored when the document is serialized without NPEs being thrown.

        Show
        Sami Siren added a comment - This does not seem to be a problem with trunk version of solrj: I can add fields with null values and they are silently being ignored when the document is serialized without NPEs being thrown.
        Hide
        Todd Feak added a comment -

        I dug a bit more on this bug. I think the null check needs to be put back into ClientUtils.writeXML that was previously there.

        This bit of code

        for( Object v : field ) {
        if (v instanceof Date)

        { v = fmtThreadLocal.get().format( (Date)v ); }

        if( boost != 1.0f )

        { XML.writeXML(writer, "field", v.toString(), "name", name, "boost", boost ); }

        else

        { XML.writeXML(writer, "field", v.toString(), "name", name ); }

        // only write the boost for the first multi-valued field
        // otherwise, the used boost is the product of all the boost values
        boost = 1.0f;
        }

        is vulnerable to an NPE if the value of a field is null. The value of a field will only come back as null for a multi-valued field containing a null. This cannot be completely guarded against at the SolrInputDocument level, as it's impossible to tell if a field is multi-valued or not the first time it is put in.

        Patch coming soon.

        Show
        Todd Feak added a comment - I dug a bit more on this bug. I think the null check needs to be put back into ClientUtils.writeXML that was previously there. This bit of code for( Object v : field ) { if (v instanceof Date) { v = fmtThreadLocal.get().format( (Date)v ); } if( boost != 1.0f ) { XML.writeXML(writer, "field", v.toString(), "name", name, "boost", boost ); } else { XML.writeXML(writer, "field", v.toString(), "name", name ); } // only write the boost for the first multi-valued field // otherwise, the used boost is the product of all the boost values boost = 1.0f; } is vulnerable to an NPE if the value of a field is null. The value of a field will only come back as null for a multi-valued field containing a null. This cannot be completely guarded against at the SolrInputDocument level, as it's impossible to tell if a field is multi-valued or not the first time it is put in. Patch coming soon.
        Hide
        Todd Feak added a comment -

        For our use, I will be subclassing the SolrInputDocument class and putting null checks there. This avoids having to maintain a different version of this library.

        My question is this, is putting the same null checks into the SolrInputDocument class itself a valuable solution? If so, I can create a patch and submit it here. Looking for feedback from the devs on whether or not this is a desirable solution.

        Show
        Todd Feak added a comment - For our use, I will be subclassing the SolrInputDocument class and putting null checks there. This avoids having to maintain a different version of this library. My question is this, is putting the same null checks into the SolrInputDocument class itself a valuable solution? If so, I can create a patch and submit it here. Looking for feedback from the devs on whether or not this is a desirable solution.

          People

          • Assignee:
            Unassigned
            Reporter:
            Todd Feak
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development