gerlowskija commented on code in PR #975:
URL: https://github.com/apache/solr/pull/975#discussion_r966121020
##########
solr/core/src/java/org/apache/solr/handler/admin/api/SchemaNameAPI.java:
##########
@@ -46,7 +46,7 @@ public SchemaNameAPI(SolrCore solrCore) {
}
@GET
- @Produces("application/json")
+ @Produces({"application/json", "application/xml", "application/javabin"})
Review Comment:
Turns out I had to fight SolrJ a bit to get this working. I've pushed up a
commit to get it working (see
[here](https://github.com/apache/solr/pull/975/commits/565fb9cd3c37c5572d7ea9a4c9007dd623627c18)
), but I'm on the fence whether we should include it in this PR or whether
it'd be better to stick with "application/octet-stream" for now and switch the
mime type down the road.
The root of the issue is that the `getContentType()` method on SolrJ's
`ResponseParser` interface returns a single string. That is, ResponseParsers
declare a single content-type that they can handle, and SolrJ will throw an
error if Solr's response comes back with any other 'Content-Type' value. This
is a problem for us since we want BinaryResponseParser to support the new media
type while maintaining compatibility with existing v1 and v2 requests that
return `application/octet-stream`.
The linked commit works around this by adds a
`ResponseParser.getContentTypes()` (note the plural) method for returning
multiple content-types, deprecates the existing "single-string"
`getContentType`, and updates the SolrClient usage to rely on the new method.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
