[
https://issues.apache.org/jira/browse/SOLR-17705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18034873#comment-18034873
]
David Smiley commented on SOLR-17705:
-------------------------------------
This issue replaced {{JacksonParsingResponse}} with
{{JacksonDataBindResponseParser}} (which was in turn introduced by
[~gerlowskija] some time prior), but I didn't notice the inappropriateness of
the package – {{{}org.apache.solr.client.solrj}. This belongs in
{{org.apache.solr.client.solrj.response{}}}, perhaps even the \{{json}
sub-package. I propose that this disorganization be corrected for 10.0. WDYT
Jason? We could correct several disorganizations in one go/PR.
> SolrJ SolrRequest's parameterized type should be unbounded
> ----------------------------------------------------------
>
> Key: SOLR-17705
> URL: https://issues.apache.org/jira/browse/SOLR-17705
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Fix For: 10.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> _(Two theme alignments here: V2 API migration, and NamedList reduction)_
> SolrJ SolrRequest has a parameterized type of its response type that is bound
> to be of type SolrResponse. SolrResponse isn't an interesting class; it just
> holds the "response" NamedList, has the elapsed time, and has a utility
> method to extract an exception from the named list (maybe shouldn't be
> there...). The most central aspect of what little there is, is the
> NamedList, which is obtainable from all SolrRequests and is more omnipresent
> than it'd ideally be (see SIP-22 for reduction). I'd like to change this
> parameterized type to be unbounded, thus could return anything that isn't
> necessarily a subclass of SolrResponse. This is more flexible (useful for
> V2), and it lessens the insistence on responses having a NamedList. It's up
> to the SolrRequest subclass to create the response, populating it from the
> *internal* NamedList passed from the SolrClient's request method. This
> already happens somewhat in SolrRequest.createResponse (protected), but would
> need some adjustments in my proposal here. Our V2 "api" module has classes
> in which SolrJerseyResponse is the base class of API methods, which is *not*
> a subclass of SolrResponse, so there's additional wrapping indirection that
> could go away with this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
