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

Reply via email to