gerlowskija commented on PR #2510: URL: https://github.com/apache/solr/pull/2510#issuecomment-2159142519
Hey @malliaridis - thanks for the fix, and thanks even more for the detailed writeup. I wish everyone (myself included) was so thorough in listing out other potential approaches. This is awesome! Ultimately I think the approach you took here is the best one available for now. As you pointed out, it does have the downside that it requires all response classes to live in the same package. I agree this is non-ideal, but something we can live with. In fact, there are actually one or other two places where the template relies on the "single package" assumption. I tried hard to avoid it in the initial implementation, but couldn't crack it entirely at the time. In hindsight I think we could probably do something based on vendor-extension annotations (like the one used in [SelectApi](https://github.com/apache/solr/blob/a42c605fb916439222a086356f368f02cf80304a/solr/api/src/java/org/apache/solr/client/api/endpoint/SelectApi.java#L69-L74)), but that'd require a larger effort than just fixing this bug. > It is possible to add a generics bound in JacksonParsingResponse<T> that limits T to only classes that extend SolrJerseyResponse, but this will limit the possible classes for T I think this would probably be OK as a longer-term solution. Though I wonder about a few APIs that return "blobs" of data (e.g. returning a single file out of a configset). These responses are "just" raw data, so they don't quite fit into the `SolrJerseyResponse` model which assumes at least a bare minimum of structure (e.g. `responseHeader`). That feels like a solve-able problem, but it might take some thought... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
