Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] [External] : Re: Jakarta REST 4.0 - Brainstorming

Regarding Jakarta Config, you don't actually need a compile-time dependency. Java SE Bootstrapping for example is already supporting it by simply accepting a functional interface ("property resolution method"), which "by sheer chance" ;-) is identical to the one implemented by Jakarta Config. Hence, you do need a single code line to wire it, but it does work. Maybe we can find a similar solution for the EE environment, too, and reduce the actual reference to a few explanatory examples in the spec?

-Markus

 

Von: jaxrs-dev [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Santiago Pericasgeertsen
Gesendet: Montag, 24. Mai 2021 20:23
An: jaxrs developer discussions
Betreff: Re: [jaxrs-dev] [External] : Re: Jakarta REST 4.0 - Brainstorming

 

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

 

 

On Fri, May 21, 2021 at 9:49 AM Santiago Pericasgeertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:

Hi All,

 I put together some slides with thoughts about Jakarta REST 4.0 and CDI. Also created a branch in my fork that includes all the necessary changes to build a small sample.

 Hope you find this useful to get us started.

— Santiago

[1] https://github.com/spericas/jaxrs-api/blob/release-4.0/JakartaRest40.pdf
[2] https://github.com/spericas/jaxrs-api/tree/release-4.0


_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jaxrs-dev

_______________________________________________
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$

 


Back to the top