You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Todd Feak (JIRA)" <ji...@apache.org> on 2008/12/05 19:42:44 UTC

[jira] Created: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value

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: Trivial


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.


[jira] Commented: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value

Posted by "Todd Feak (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Commented: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value

Posted by "Todd Feak (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655394#action_12655394 ] 

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

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.

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


[jira] Updated: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value

Posted by "Todd Feak (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Feak updated SOLR-899:
---------------------------

    Priority: Minor  (was: Trivial)

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