Hi all, I recently spent some time on SOLR-15070 - a SolrJ ClassCastException that cropped up for a customer hitting /suggest with wt=xml. SOLR-15070 itself was a relatively straightforward fix, but the more I think about the underlying cause the more I wonder whether we don't have a larger, fundamental problem in how our ResponseParser's/codec's work in SolrJ. I wanted to run it by everyone here.
My understanding of SolrJ's response serialization/deserialization was that responses from Solr are supposed to deserialize to the same NamedList on the client side, regardless of the wire format Solr used to send the response. This guarantee is seemingly important for other classes in SolrJ as well as for users who inspect NamedList's directly - it would be a big burden if (e.g.) SolrJ's QueryResponse had to handle the slight divergences of responses in 3 or 4 different formats. But in working on SOLR-15070 I noticed that ResponseParser's don't even support the same "collection" types in their deserialization. BinaryResponseParser (the default) creates structures containing ArrayLists, SimpleOrderedMaps, NamedLists, and HashMaps. XMLResponseParser only supports a subset of those: ArrayLists and SimpleOrderedMaps. Any API that triggers any of javabin's unique mappings then will by necessity result in different NamedList structures on the client side. The biggest problem in practice here is probably "Map". Is my understanding of how NamedList and ResponseParsers are supposed to work correct? If so, has anyone else noticed the divergence between the supported output-types before? Does anyone have opinions on a fix? Presumably this would require bringing our ser/de code for other formats up to par with javabin, which seems like a big breaking change for those formats. Just fishing for general thoughts and advice I guess. Best, Jason --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
