[
https://issues.apache.org/jira/browse/SOLR-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896453#comment-17896453
]
David Smiley commented on SOLR-17549:
-------------------------------------
To learn more, I tracked down this getParsed method (on
org.apache.solr.client.solrj.JacksonParsingResponse). It only has one non-test
caller and one test caller. I'd expect that we want this new API to be more
widespread but maybe it's so young that our new SolrJ framework is barely if at
all even really {_}used{_}? Then we can definitely expect bugs/shortcomings and
can't recommend it to users {_}yet{_}.
I'd like to suggest renaming getParsed to getResponseObject so as to make it
familiar to us calling getResponse (a NamedList) but Object shows we've
deserialized the response to something. JacksonParsingResponse.getResponse
should be overridden to throw UnsupportedOperationException. Or alternatively
we make getResponse's return value be a parameterized type but that could be a
huge change (unsure). BTW JacksonParsingResponse is a public class lacking
javadoc.
> Reconsider error-handling in generated-v2 SolrResponses
> -------------------------------------------------------
>
> Key: SOLR-17549
> URL: https://issues.apache.org/jira/browse/SOLR-17549
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Priority: Major
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
