[
https://issues.apache.org/jira/browse/SOLR-15070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-15070.
------------------------------------
Fix Version/s: master (9.0)
8.8
Resolution: Fixed
I've committed fixes for both 8.8 and 9.0.
To maintain back-compatibility and avoid changing the API, the 8.8 fix changes
the response parsing code in QueryResponse to just check for both types
(NamedList and Map), and then massage the NamedList version as necessary to
avoid exceptions when building the SuggesterResponse.
The fix in 9.0/master changes Solr's server-side suggest component to avoid use
of the HashMap type, which avoids the discrepancy altogether.
> SolrJ ClassCastException on XML /suggest requests
> -------------------------------------------------
>
> Key: SOLR-15070
> URL: https://issues.apache.org/jira/browse/SOLR-15070
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, Suggester
> Affects Versions: 8.6.3, master (9.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Minor
> Fix For: 8.8, master (9.0)
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SolrJ throws a ClassCastException when parsing XML {{/suggest}} responses.
> The following code snippet (run against the techproduct example) produces the
> stack trace that follows:
> {code}
> public void testSuggestFailure() throws Exception {
> HttpSolrClient client = new HttpSolrClient.Builder()
> .withBaseSolrUrl("http://localhost:8983/solr/techproducts";)
> .withResponseParser(new XMLResponseParser())
> .build();
> Map<String, String> queryParamMap = new HashMap<>();
> queryParamMap.put("qt", "/suggest");
> queryParamMap.put("suggest.q", "elec");
> queryParamMap.put("suggest.build", "true");
> queryParamMap.put("suggest", "true");
> queryParamMap.put("suggest.dictionary", "mySuggester");
> queryParamMap.put("wt", "xml");
> QueryResponse resp = client.query(new MapSolrParams(queryParamMap));
> }
> {code}
> {code}
> java.lang.ClassCastException: class
> org.apache.solr.common.util.SimpleOrderedMap cannot be cast to class
> java.util.Map (org.apache.solr.common.util.SimpleOrderedMap is in unnamed
> module of loader 'app'; java.util.Map is in module java.base of loader
> 'bootstrap')
> at
> org.apache.solr.client.solrj.response.QueryResponse.setResponse(QueryResponse.java:170)
> ~[solr-solrj-8.4.1.jar:8.4.1 832bf13dd9187095831caf69783179d41059d013 -
> ishan - 2020-01-10 13:40:30]
> at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
> ~[solr-solrj-8.4.1.jar:8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan
> - 2020-01-10 13:40:30]
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
> ~[solr-solrj-8.4.1.jar:8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan
> - 2020-01-10 13:40:30]
> at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1018)
> ~[solr-solrj-8.4.1.jar:8.4.1 832bf13dd9187095831caf69783179d41059d013 - ishan
> - 2020-01-10 13:40:30]
> {code}
> SolrJ's {{QueryResponse}} expects the "suggest" section in the NamedList
> response to be a Map - and for requests that use javabin (the default
> ResponseParser), it is. But when parsing XML responses the "suggest" section
> deserialized as a SimpleOrderedMap (which despite the name doesn't implement
> Map).
> The root cause afaict is that SuggestComponent [uses a
> type|https://github.com/apache/lucene-solr/blob/43b1a2fdc7a4bf8e5c8409013d07858dec6d0c35/solr/core/src/java/org/apache/solr/handler/component/SuggestComponent.java#L261]
> (HashMap) that serializes/deserializes differently based on the codec/wt
> used on the wire. JavaBinCodec has special handling for maps that our XML
> serialization doesn't have, so the two produce different response structures
> on the client side.
> The "right" fix here is to change SuggestComponent's response to only use
> types that serialize/deserialize identically in all SolrJ's ResponseParser's.
> This is a breaking change though - a SolrJ user making /suggest requests,
> getting the responses via javavbin, and inspecting the resulting NamedList
> directly would get a different object tree after this fix than they would've
> before. So an 8.x fix would need to take a different approach.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
