dsmiley commented on code in PR #3876:
URL: https://github.com/apache/solr/pull/3876#discussion_r2573957180
##########
solr/solrj/src/java/org/apache/solr/client/solrj/impl/PreemptiveBasicAuthClientCustomizer.java:
##########
@@ -66,15 +68,15 @@ public static void setDefaultSolrParams(SolrParams params) {
}
@Override
- public void close() throws IOException {}
-
- @Override
- public void setup(Http2SolrClient client) {
+ public void setup(SolrClient client) {
+ if (client instanceof Http2SolrClient == false) {
+ return;
+ }
Review Comment:
Perhaps it's a matter of taste, but I'd rather have a common interface with
one setup method (as I propose here), than either multiple type-specific
classes or type-specific methods. Perhaps adding generics would help slightly,
in terms of making an implementation clearly for a specific type. Yeah.
> My main interest here is around the Java API / signature itself. It feels
to me like the type-widening results in a Java API that's easier for a SolrJ
user to misuse, and harder for a Solr developer to implement than it was before.
I don't agree/understand this concern. I'll update this PR soon-ish after
another big PR lands. Perhaps you'll feel better about it. If you don't; I'm
ready to give up and do what you think I should do (which I'm not 100% clear on
what that is).
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
