Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jersey fails to respond with wildcard generics #5328

Closed
mkarg opened this issue May 12, 2023 · 3 comments · Fixed by #5331
Closed

Jersey fails to respond with wildcard generics #5328

mkarg opened this issue May 12, 2023 · 3 comments · Fixed by #5331

Comments

@mkarg
Copy link
Member

mkarg commented May 12, 2023

Problem Description

Apparently Jersey 3.x has problems with serving wildcard generics.

Serving wildcard generics was working successfully on Jersey 2.x, and it still is working successfully on RESTeasy, so I assume it is a bug introduced by Jersey 3. I also do not see that the JAX-RS spec forbids wildcards.

Reproducer

When running the following code on Jersey, serving /a succeeds, while serving /b fails with status code 500.

package eu.headcrashing.jaxrsdoneright.sebootstrap;

import java.util.Set;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CompletionStage;

import jakarta.ws.rs.ApplicationPath;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.SeBootstrap;
import jakarta.ws.rs.core.Application;

public class Reproducer {

    public static void main(String[] args) throws InterruptedException {
        SeBootstrap.start(App.class).thenAccept(instance -> {
            var actualConfig = instance.configuration();
            System.out.println("BaseURI: " + actualConfig.baseUri());
        });
        Thread.currentThread().join();
    }

    @ApplicationPath("")
    public static class App extends Application {
        public Set<Class<?>> getClasses() {
            return Set.of(Res.class);
        }
    }

    @Path("")
    public static class Res {
        @GET @Path("a")
        public CompletionStage<? extends String> a() {
            return CompletableFuture.completedStage("hello");
        }

        @GET @Path("b")
        public CompletionStage<String> b() {
            return CompletableFuture.completedStage("hello");
        }
    }
}

The failing GET /b tells us:

Mai 12, 2023 8:11:03 AM org.glassfish.jersey.internal.Errors logErrors
WARNUNG: The following warnings have been detected: WARNING: Return type, java.util.concurrent.CompletionStage<? extends java.lang.String>, of method, public java.util.concurrent.CompletionStage<? extends java.lang.String> eu.headcrashing.jaxrsdoneright.sebootstrap.Reproducer$Res.a(), is not resolvable to a concrete type.

...

Mai 12, 2023 8:11:09 AM org.glassfish.jersey.server.ServerRuntime$Responder process
WARNUNG: An exception mapping did not successfully produce and processed a response. Logging the exception propagated to the default exception mapper.
java.lang.IllegalArgumentException: Type parameter ? extends java.lang.String not a class or parameterized type whose raw type is a class
        at jakarta.ws.rs.core.GenericType.getClass(GenericType.java:173)
        at jakarta.ws.rs.core.GenericType.<init>(GenericType.java:132)
        at org.glassfish.jersey.message.internal.OutboundMessageContext.setEntityType(OutboundMessageContext.java:763)
        at org.glassfish.jersey.server.ContainerResponse.setEntityType(ContainerResponse.java:313)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.lambda$invoke$2(ResourceMethodInvoker.java:471)
        at org.glassfish.jersey.process.internal.Stages$LinkedStage.apply(Stages.java:284)
        at org.glassfish.jersey.process.internal.Stages.process(Stages.java:147)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:383)
        at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:375)
        at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:264)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:240)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:697)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:367)
        at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:190)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
        at java.base/java.lang.Thread.run(Unknown Source)

Mai 12, 2023 8:11:09 AM org.glassfish.jersey.server.ServerRuntime$Responder writeResponse
SCHWERWIEGEND: Error while closing the output stream in order to commit response.
java.lang.IllegalStateException: Illegal attempt to call getOutputStream() after getWriter() has already been called.
        at org.glassfish.grizzly.http.server.Response.getNIOOutputStream(Response.java:578)
        at org.glassfish.grizzly.http.server.Response.getOutputStream(Response.java:602)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer$ResponseWriter.writeResponseStatusAndHeaders(GrizzlyHttpContainer.java:250)
        at org.glassfish.jersey.server.ServerRuntime$Responder$1.getOutputStream(ServerRuntime.java:667)
        at org.glassfish.jersey.message.internal.CommittingOutputStream.commitStream(CommittingOutputStream.java:171)
        at org.glassfish.jersey.message.internal.CommittingOutputStream.flushBuffer(CommittingOutputStream.java:276)
        at org.glassfish.jersey.message.internal.CommittingOutputStream.commit(CommittingOutputStream.java:232)
        at org.glassfish.jersey.message.internal.CommittingOutputStream.close(CommittingOutputStream.java:247)
        at org.glassfish.jersey.message.internal.OutboundMessageContext.close(OutboundMessageContext.java:865)
        at org.glassfish.jersey.server.ContainerResponse.close(ContainerResponse.java:389)
        at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:749)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:385)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponseWithDefaultExceptionMapper(ServerRuntime.java:633)
        at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:458)
        at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:269)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:265)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:240)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:697)
        at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:367)
        at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:190)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
        at java.base/java.lang.Thread.run(Unknown Source)
@jansupol
Copy link
Contributor

  1. It does not seem to work in 2.x
  2. I assume serving /a fails while serving /b passes
  3. It is a corner-case
  4. The support for this (I assume a new feature) is implementable

@jansupol jansupol linked a pull request May 12, 2023 that will close this issue
@mkarg
Copy link
Member Author

mkarg commented May 12, 2023

  1. It works pretty well on Payara 5, which is based on Jersey 2.
  2. Yes.
  3. So what?
  4. As we are using it in production on Payara 5, hence Jersey 2, it cannot be a new feature but actually making it work again.
  5. It works pretty well on RESTeasy.

@mkarg
Copy link
Member Author

mkarg commented Mar 20, 2024

I confirm that I cannot reproduce the bug anymore using Jersey v. 3.1.5.payara-p1 as part of Payara 6.2024.3.

I assume that earlier and non-payara-specific versions do contain the same fix, but I did not find the time to test them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants