[
https://issues.apache.org/jira/browse/SOLR-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley reassigned SOLR-17549:
-----------------------------------
Assignee: David Smiley
Priority: Blocker (was: Major)
Updating to Blocker as I see us overhauling the ResponseParser API. Need to
make big changes like that in a major release. Assigning to me.
> Reconsider error-handling in generated-v2 SolrResponses
> -------------------------------------------------------
>
> Key: SOLR-17549
> URL: https://issues.apache.org/jira/browse/SOLR-17549
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: David Smiley
> Priority: Blocker
>
> In most cases upon receiving an HTTP response, SolrClients will immediately
> parse it into a NamedList and then inspect that NamedList to see whether a
> client-side exception should be triggered.
> Our generated v2-API SolrRequest/SolrResponse classes work differently. They
> never convert the response into a NamedList, instead using Jackson to put it
> into a strongly-typed POJO. Additionally, response parsing occurs lazily -
> typically not until after the SolrResponse has been returned to callers and
> they've invoked a special "getParsed()" method.
> The combined effect of these two differences is that all of the
> error-detection/exception-throwing code in SolrClient is skipped when making
> generated-v2 requests! Callers can still detect errors by manually
> inspecting their response POJOs, but anyone expecting SolrJ's "no exception
> means success" convention are in for a frustrating shock.
> We should change how response-parsing happens in the generated-v2 case to
> match the rest of SolrJ. (Or alternately - investigate some more intuitive
> way to communicate failure.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
