gharris1727 commented on a change in pull request #11369:
URL: https://github.com/apache/kafka/pull/11369#discussion_r720410705
##########
File path: clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java
##########
@@ -1116,11 +1119,79 @@ public void ensureValid(String name, Object value) {
}
}
+ @Override
public String toString() {
return "non-empty string without ISO control characters";
}
}
+ public static class InstantiableClassValidator implements Validator {
+ @Override
+ public void ensureValid(String name, Object value) {
+ if (value == null) {
+ // The value will be null if the class couldn't be found; no
point in performing follow-up validation
+ return;
+ }
+
+ Class<?> cls = (Class<?>) value;
+ try {
+ cls.getDeclaredConstructor().newInstance();
Review comment:
No, I don't think that buys us much, as the developer using this
validator won't have much more insight into the arbitrary classes' behavior
than the developer writing this validator.
Perhaps we could combine these two validators, or make the execution of this
one dependent on the subclass validator, to try to narrow down the range of
classes that could be instantiated here. For example, if the user is supposed
to provide a HeaderConverter class, the typical HeaderConverter class will have
a non-leaky default constructor.
...Except i just looked through the API definitions, and I don't think the
javadocs for any of our API classes talk about default constructors and
expectations, I'd have to dig deep to find out where this expectation is
documented, if it exists. Maybe checking the subclass doesn't buy ourselves
anything.
If you want to write a validator like this, I think the only justification
we can have is that if it causes a memory leak, that's the implementation's
fault because the framework never had any guarantees on the number of objects
instantiated.
LGTM.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
