You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2024/10/17 01:39:00 UTC
[jira] [Updated] (SOLR-17390) EmbeddedSolrServer should support a ResponseParser
[ https://issues.apache.org/jira/browse/SOLR-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ASF GitHub Bot updated SOLR-17390:
----------------------------------
Labels: pull-request-available (was: )
> EmbeddedSolrServer should support a ResponseParser
> --------------------------------------------------
>
> Key: SOLR-17390
> URL: https://issues.apache.org/jira/browse/SOLR-17390
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> By default, a SolrRequest has a null/unspecified ResponseParser; it's handled automatically within SolrJ. But an explicit one communicates an intent for the client code to need it, like JsonMapResponseParser, InputStreamResponseParser, or NoOpResponseParser (particularly those 3). EmbeddedSolrServer doesn't look at this; the NamedList right out of the core/handler is normalized (via javabin round-trip) and returned. While that makes sense _normally_, a ResponseParser should also be supported. This enables tests that might want to use EmbeddedSolrServer but that which need to test JSON or XML (for convenience of xpath/json expressions, for example). Also, the newer V2 API generated clients would need this to support EmbeddedSolrServer as they are currently based off of InputStreamResponseParser.
> Doing this means determining the correct ResponseWriter (not assuming JavaBin during normalization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org