quarkus: JAX-RS Resource with Kafka Topic injection - Message body writer not found

I built an applictaion based on the tutorial https://quarkus.io/guides/kafka. The problem takes place with the json binding. The application functions correctly when the type being returned by the resource is Publisher<String> or Publisher<double>. In case of a POJO, e.g. Publisher<Fruit>, the error occurs: “Failed to write event org.jboss.resteasy.plugins.providers.sse.OutboundSseEventImpl@51eb8c1b: javax.ws.rs.ServerErrorException: RESTEASY004082: No suitable message body writer for class : org.acme.quarkus.sample.fruit.Fruit” :

@Path(“/fruits”) public class FruitPriceResource {

Logger LOG = LoggerFactory.getLogger(FruitPriceResource.class);

@Inject
@Channel("fruit-out")
Publisher<Fruit> fruits;

@GET
@Path("/stream")
@Produces(MediaType.SERVER_SENT_EVENTS)
@SseElementType(MediaType.APPLICATION_JSON)
public Publisher<Fruit> stream() {
    return fruits;
}

}

The application is in this repository. Here you can find the working example with a Publisher as well as the one with the Fruit object (the one not working). Repository: https://github.com/serranisimo/kafka-json

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 20 (13 by maintainers)

Most upvoted comments

No, it should work, and I know exactly what this bug is caused by: we scan @Produces to register only the body writers that are used, and we don’t scan @SseElementType while we should.

I bet adding this (unused endpoint) will make your app work:

@GET
@Path("/unused")
@Produces(MediaType.APPLICATION_JSON)
public Fruit unused() {
    return null;
}

It will also probably work if you add @Produces(MediaType.APPLICATION_JSON) to your endpoint class, because in both cases it will trigger registration of the json body writer.

We should totally fix this in the resteasy extension.

OK so I’m still mentally sane, it was indeed implemented already 😃.

@FroMage

we scan @Produces to register only the body writers that are used, and we don’t scan @SseElementType while we should

That’s not true. It might be flawed but we have something for it: https://github.com/quarkusio/quarkus/blob/master/extensions/resteasy-common/deployment/src/main/java/io/quarkus/resteasy/common/deployment/ResteasyCommonProcessor.java#L334 .

We need to understand why it’s not working properly in this case.

@ia3andy this would be a good starting point for you. The hard part will be to get a proper test case, then you need to tune the provider resolution.