[
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789923#action_12789923
]
Chris A. Mattmann commented on SOLR-1123:
-----------------------------------------
{quote}
I think the main issue with the inheritance right now is that the
QueryResponseWriter interface is dealing with a Writer rather than with an
OutputStream. This accounts for the hacky GenericBinaryResponseWriter.
{quote}
I'm taking a look at this.
{quote}
Looking at SOLR-1516 I'm a bit confused. I always had the impression that the
main idea behind the response writers is that all they need to know is how to
marshal a NamedList (so they don't need explicit knowledge of documents,
highlighting, etc...). But now the GenericTextResponseWriter knows about
documents (via the SingleResponseWriter). But perhaps I just go it wrong.
{quote}
Well if that's the main idea behind ResponseWriters as you put it, then as I
put it in SOLR-1516, it's pretty confusing. Users (who understand Lucene and
SOLR) know that if they query they get back o.a.lucene.Documents or
o.a.solr.SolrDocumentList, etc. The whole NamedList structure is pretty
confusing to me (and to others as I've noted on other issues and on the mailing
list). SOLR-1516 was an attempt to give those people writing ResponseWriters
(now) the ability to deal with results of queries, aka Documents (and not all
the other NamedList typeless bag of objects where you have to do instanceof
everwhere to unmarshall it). Clearly not all ResponseWriters will be able to
take advantage of this (e.g., those that need the specified output structures
provided by other components, e.g., Facets, etc.), which is why my original
patch called the two response writers I added Document*ResponseWriter b/c
that's what they dealt with.
Cheers,
Chris
> Change the JSONResponseWriter content type
> ------------------------------------------
>
> Key: SOLR-1123
> URL: https://issues.apache.org/jira/browse/SOLR-1123
> Project: Solr
> Issue Type: Improvement
> Reporter: Uri Boness
> Fix For: 1.5
>
> Attachments: JSON_contentType_incl_tests.patch
>
>
> Currently the jSON content type is not used. Instead the palin/text content
> type is used. The reason for this as I understand is to enable viewing the
> json response as as text in the browser. While this is valid argument, I do
> believe that there should at least be an option to configure this writer to
> use the JSON content type. According to
> [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to
> be application/json (and not text/x-json). The reason this can be very
> helpful is that today you have plugins for browsers (e.g.
> [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page
> with application/json content type in a user friendly manner (just like xml
> is supported).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
