We need to be able to handle resource methods with interface entity parameters and interface return values.

What I mean by this, is that it would be nice if there were some abstract types the generated source files could extend. It makes the hard-coded strings easier to read and validate via a compiler at build time instead of relying on runtime tests.

We should not use ByteArrayInputStream and ByteArrayOutputStream for communication. This could cause issues for large payloads possibly crashing the JVM with an OOME.

This is related with: resteasy/gRPCtoJakartaREST-archetype#5

We should attempt to remove the ${project.name}_Server resource requirement. It's a big awkward from a user perspective to have to ensure one end point always gets invoked before another endpoint.

I would think we could use a filter of some sort to handle this. We may have to set the servlet context on the ResteasyContext, but IMO that should be a last resort. I feel we could use a ContainerRequestFilter to set a property on the request itself.

If this cannot be removed, we really should remove the start and stop end points as they should not be publicly exposed.

Each message type should start counting fields at 1. This matters because protobuf minimizes the space used for field numbers, and the smallest numbers fit in one byte.

The changes in RESTEasy 6.2.6 cause AbstractGrpcToJakartaRESTTest.testServletParams() to fail since now HttpServletRequestImpl getParts() has to be implemented.