[
https://issues.apache.org/jira/browse/SOLR-17705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-17705.
---------------------------------
Fix Version/s: main (10.0)
Assignee: David Smiley
Resolution: Fixed
> 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: main (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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
