[ 
https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668646#action_12668646
 ] 

Todd Feak commented on SOLR-899:
--------------------------------

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.

> NullPointerException in ClientUtils.writeXML on NULL field value
> ----------------------------------------------------------------
>
>                 Key: SOLR-899
>                 URL: https://issues.apache.org/jira/browse/SOLR-899
>             Project: Solr
>          Issue Type: Bug
>          Components: clients - java
>    Affects Versions: 1.3
>            Reporter: Todd Feak
>            Priority: Minor
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to