Kotlin wizards let me hear ya. I'm using dropwizar...

# server

[muliyul]

Kotlin wizards let me hear ya.
I'm using dropwizard and I was wondering if it's possible to convert Jersey's AsyncResponse to a suspend function (supporting resource suspend functions transparently).

Existing:

class SomeResource {
  @GET
  fun someMethod(@Suspended asyncResponse: AsyncResponse) { ... }
}

Desired:

class SomeResource {
  @GET
  suspend fun someMethod() { ... }
}

[satyan]

I think you can't.
Jersey is working with some annotation processing right ?
The only ways would be for the annotation processors to be able to recognize that the method is suspendable and generate the relevant code.

Retrofit for example (a HTTP Client wrapper for OKHttp commonly used in Android) recently added support for suspend function by adding a built-in adapter (Adapter handle the return type of your services interfaces methods. )

[muliyul]

I think what I'm really asking is there a way to extend jersey's annotation processing but that does not belong here.

[tddmonkey]

I’d be interested in hearing how you solve it though

[satyan]

Maybe this could be a good direction for you:

https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/message-body-workers.html

[Joe]

quickly put together a PoC implementation here: https://github.com/trib3/leakycauldron/compare/wip-coroutine-jersey-handler?expand=1 not fully tested or documented yet but appears to work with simple things. probably would want a way to specify which dispatcher to use, maybe some more per-endpoint configuration?

[Joe]

fwiw, the above doesn't yet work for methods that take a body (eg, POST/PUT with body), and it warns but works on body-less methods (eg simple GET). I suspect a ModelProcessor that rebuilds the resource model ignoring the Continutation parameter is the way to fix that, but haven't gotten it to work yet.

[muliyul]

@Joe thanks it's really helpful. I would like it to work for all types of requests I'll see if I can make it work.

[Joe]

getting closer w/ the ModelProcessor approach, but currently losing parameter annotations (eg @QueryParam("argName")) when creating a copy of the resource method via javassist/bytebuddy. That approach seems better than the current commit, but generating the method @ runtime is being a little tricky.

[Joe]

ok, https://github.com/trib3/leakycauldron/pull/643 appears to work now. We don't use subresources so I'm not exactly sure what the subresource method of the processor should do, but I think it makes sense to process those like regular resources. open to any input there

[muliyul]

Neat! we don't use sub resources either. I think it makes sense to process them as regular resources.
Another suggestion: allow the dispatcher to be defined in the class level. Either by annotation, as a field (implements CoroutineScope).
If I want to use this, how do I import without the extra libraries in the repo?

[Joe]

👍 good suggestions, those will go in and will probably cut a 1.12.x release of the repo today or tomorrow. re: not using everything, we're not really set up for that level of modularization and that probably won't change any time soon. But you might could import the com.trib3:server jar, exclude all transitive deps, and only reference the CoroutineModelProcessor class in your codebase.... it'll still add all our classes to the classpath, but they shouldn't even get loaded by any classloaders as long as nothing references them (I think but have not tried!). Otherwise you could play around with unpack/repacking the jar in your build but that may or may not get more complex than is worth?

[Joe]

(did release that yesterday fwiw)

[muliyul]

I saw, nice work. Works pretty well. Do you mind if I use it in our project with reference? We're not interested in the rest of the jar.

[Joe]

It's ASL2 licensed, so use it with those terms in whatever way works best for you

[Joe]

https://github.com/trib3/leakycauldron/commit/9e0ab3da01f6033e7893c93afae17b90445d053f fyi

[muliyul]

Thanks for the update @Joe!.

[Joe]

a few minor fixes to this if anyone's still using a forked version of the code: https://github.com/trib3/leakycauldron/commit/22a40d95c8354ad519632060ba72d862f070946f

[Joe]

and one more to fix a race condition with sse/AsyncResponse code: https://github.com/trib3/leakycauldron/commit/75a59a0ff16575d2d500756dffac44ee012a50d4