[
https://issues.apache.org/jira/browse/SOLR-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-2085.
----------------------------
Resolution: Fixed
Fix Version/s: 4.0
3.1
Assignee: Hoss Man
Thanks for the patch Tomas.
By the looks of it, someone already fixed the NPE, but the code would still
behave differently depending on the output order -- i've added your patch along
with a note about why delayed execution is important.
Committed revision 1064386. - trunk
Committed revision 1064390. - 3x
> SolrJ fails with a NullPointerException when the order of result components
> changes
> -----------------------------------------------------------------------------------
>
> Key: SOLR-2085
> URL: https://issues.apache.org/jira/browse/SOLR-2085
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.4
> Reporter: Tomas Salfischberger
> Assignee: Hoss Man
> Priority: Critical
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-2085-QueryResponse.patch
>
>
> When using a custom search component in Solr I noticed that the order of the
> "params", "response" and "facet_counts" fields in the response changed.
> Normally the "response" field is included before the "facet_counts" field,
> but in my result it first returned "facet_counts" and then "response". This
> is of course a valid and semantically identical result object, but it causes
> SolrJ to fail with a NullPointerException.
> The reason for this NPE is that SolrJ in
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(NamedList<Object>
> res) uses a loop through the response components and right after
> encountering "facet_counts" calls extractFacetInfo( _facetInfo ). That method
> uses _results which is null if the "response" component has not been
> encountered yet. (It is handled and set a few lines above the call to
> extractFacetInfo).
> The solution is to move the call to extractFacetInfo() on line 99 out of the
> for-loop. Please see the attached simple patch for the solution.
> I have also checked the three other initialization calls that are made
> directly after encountering a result (extractDebugInfo,
> extractHighlightingInfo and extractSpellCheckInfo), the problem does not
> apply to those because the methods don't access global fields that need to be
> initialized.
> Note: It would be great if this could be applied to a maintenance release as
> it saves people from running a custom build to be able to use complex search
> components with SolrJ.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
