Same thought. Why the need for @Entity and @Inject on @Param.
See response to Markus.
Also, I believe many will use the new records for their data-transfer-objects, so it will be good considering it with the next releases.
It would be nice, but requires some coordination with the platform.
I am just a regular user with little understanding of the underhood technical details. So maybe there is some good reason for adding the extra annotation, other than that, I feel we will be good without them.
Breaking compatibility? I believe we should, to get a fresh foundational stuff.
Dropping @Context is already backward incompatible, so it is done deal in 4.0.
— Santiago
Santiago,
thank you so much for kicking off this discussion! I really like the idea that components and applications become good CDI-citizen!
I like your draft, but as I am not a CDI expert I do have some (possibly dumb) questions:
* Is @Inject really needed for @*Param, or can we tell CDI that @*Param shall *imply* @Inject?
* Why do we need @Entity?
* If a provider is @ApplicationScoped, is it still possible to inject request-bound information (like the current SecurityContext) into a field (I assume this would inject an @ApplicationScoped wrapper in that case which dynamically forwards to the actual request-bound
information "under the hood")?
I also would like to add one more general topic to the 4.0 list: Supporting modern Java. This means, we should be able to run on JRE 17 as this is the next LTS version, and we should clarify with the Jakarta EE team what the minimum JRE for Jakarta EE 10 is.
We also should discuss whether records and sealed classes needs special support in Jakarta REST 4.0 as I assume both become rather popular in the next months.
And finally, we should discuss if we adopt the var keyword in (new / legacy / no) source code, as it makes the code less verbose and easier to read.
BTW, I still do like the idea of founding a new open source project which is separated from Jakarta REST but is driven by the same people, holding non-foundational but commonly needed components (like libraries of more status codes, or like zip compression
filters, etc.); in the end, everything that is *not essentially* needed directly inside of the
javax.ws.rs.* packages ("syntactic sugar and DRY"). While this is a bit off-topic, breaking backwards compatibility with 4.0 would allow us to MOVE some of the existing stuff from JAX-RS to such a library. Hence, what
I like to propose for 4.0 is that we strip JAX-RS down to the foundational stuff, i. e. keep only that parts that component providers and application vendors CANNOT write on their own in a portable way.
Thanks!
-Markus
-----Ursprüngliche Nachricht-----
Von: jaxrs-dev [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] Im Auftrag von Santiago Pericasgeertsen
Gesendet: Freitag, 21. Mai 2021 16:49
An: jaxrs developer discussions
Betreff: [jaxrs-dev] Jakarta REST 4.0 - Brainstorming
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://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!Pe9-hH1M0LovaqB8xYGttkaTlOkwBpF7K8tMRdqeec0xYzxGgandM5go9ICYrP1T46GoeqE7-Q$
|
