: We are using Solrj to query our solr server, and it works great. : However, it uses the binary format wt=javabin, and now when I'm trying : to get better debug output, I notice a problem with this. The thing is, : I want to include the explain data for each search result, by adding : "[explain]" as a field for the fl parameter. And when using [explain : style=nl] combined with wt=json, the explain output is proper and valid : json. However, when I use something other than wt=json, the explain : output is not proper json.
Forget about qt param and/or the responsewriter/response parser used by SolrJ for a minute. When you use "fl=[explain style=nl]" what's happening is that *structured* named list containing hte explanation metadata is included in each document in the response -- as opposed to "style=text" in which a simple whitespace indented string representation of the score explanation is included. Now lets think about the "wt" param -- that controls how *structured* data is written over the wirte -- so with "fl=[explain style=nl]" the structurred score explanation is written over the wire as json with wt=json, or xml with wt=xml, or in solr's custom binary protocol with wt=javabin. As a SolrJ user, regardless of what "wt" value is used by SolrJ under the covers, SolrJ will use an appropriate response parser to recreate the structure of the data in your client application. So what you get in your java application when you access that psuedo-field on each document is going to depend on the (effective) "style" value of that transformer -- not the "wt" used. So for "style=text" your client code will find a java.lang.String containing the same simple string representation mentioned above (just like you see in your browser with wt=json or wt=xml). for "style=nl" you're going to get back and org.apache.solr.common.NamedList object (with the same structure as what you would see in your browser with wt=xml or wt=json) which you can traverse using the appropriate java methods to pull out the various keys & values that you want. if you simply call toString() on this object you're going to get a basic dump of the data which might look like broken JSON, but is relaly just an attempt at returning some useful toString() info for debugging. I suspect that "NamedList.toString()" output is what's confusing you... : And, the reason I want to explain segment in proper json format, is that : I want to turn it into a JSONObject, in order to get proper indentation : for easier reading. Because the regular output doesn't have proper : indentation. in your java code, you can walk the NamedList structure you get back recursively, and call the appropraite methods to get the list of key=>val pairs to add them to convert it to a JSONObject. There is no server side option to write the explain data back as a "String contianing a JSON representation of the structured data" which will then be passed as a raw string all the way back to the client. -Hoss http://www.lucidworks.com/