Hi Andy,
This is very nice! I really like the integration with CDI and being able to reduce redundant code (like @Suspended AsyncResponse, removing @Context for Sse, etc.). I also like the idea of supporting 0 or >1 Application subclasses.
Great.
The injection of @*Param into constructors will only work with @RequestScoped resources (especially in cases like slide 4 where the param is a String - which is final, so cannot be proxied), so we will need some language (and probably test cases)
that prevent that with @ApplicationScoped resources.
Yes, implementations would need to check that.
In general, I'm +1 for supporting the Flow APIs for SSEs. We did something similar for MP Rest Client (using Reactive Streams since we had to support Java 8). I think this will simplify the process of sending asynchronous events.
Absolutely.
Some other thoughts for 4.0 (mostly half-baked at best...):
* Is there anything we can do with HTTP/2?
Server push for example?
* Pull in the MP Rest Client?
Sure, this is more political than technical.
* Utilize Jakarta Config for runtime properties? Perhaps make Jakarta Config properties available in Application#getProperties()?
Perhaps, but not sure we want to have a compile-time dependency with Config.
Our roadmap page[1] also mentions a 3.2 release. Are we still thinking of doing that? I think I'd prefer to skip 3.2 and go straight to 4.0 after we complete 3.1.
We should probably update that. Feel free.
— Santiago
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jaxrs-dev__;!!GqivPVa7Brio!LlpBJIABDxI5RdkaiyFAa34IacBsMtPd23fo9nKKiYE4s8U02SD60_Sz1GyVHEHfXRzrs1AESQ$
|
