gharris1727 commented on code in PR #15149:
URL: https://github.com/apache/kafka/pull/15149#discussion_r1445300416
##########
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/rest/resources/ConnectResource.java:
##########
@@ -16,12 +16,15 @@
*/
package org.apache.kafka.connect.runtime.rest.resources;
+import javax.ws.rs.container.ContainerRequestContext;
+import javax.ws.rs.container.ContainerRequestFilter;
+import java.io.IOException;
import java.util.concurrent.TimeUnit;
/**
* This interface defines shared logic for all Connect REST resources.
*/
-public interface ConnectResource {
+public interface ConnectResource extends ContainerRequestFilter {
Review Comment:
I found an alternative workaround, it's up to you if you like it better or
worse than adding the no-op filter method.
The logic for emitting that warning in `Providers.checkProviderRuntime` is
checking that there is something to constrain the component being checked to
the current runtime (client vs server). The ContainerRequestFilter is marked as
introducing a SERVER constraint in `Providers.getJaxRsProviderInterfaces`, and
by extending it we are just inheriting that constraint.
Instead we can use the annotation mechanism intended for adding constraints
to third-party SPIs to make the ConnectResource itself look like an SPI to
Jersey. I tried adding this to the classes themselves next to the `Singleton`
annotations, and it exploded. But it seems to work when the annotations are
here on the interface instead.
```suggestion
@Contract
@ConstrainedTo(RuntimeType.SERVER)
public interface ConnectResource {
```
--
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
