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