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