| Re: [jaxrs-dev] [External] : Please help unsubscribe |
Prateek Tripathi
Generally, you should be able to modify your list subscriptions
by browsing to accounts.eclipse.org and logging into your Eclipse
developer account. Then click on the Mailing Lists Tab. From
there, you can see all your list subscriptions and by clicking the
links you should be able to adjust your subscriptions as you like.
If that doesn't work, please e-mail mailman@xxxxxxxxxxx describe
the problem and ask for help.
Thanks,
-- Ed
Hi,
I am not sure whom to contact for unsubscribing from mail list.I have tried the link provided for unsubscribing but no luck.Everytime I get is below message.Please help
You have a pending request to unsubscribe you from the jaxrs-dev mailing list.
Regards
Prateek Tripathi
On Tue, 25 May, 2021, 6:47 PM Santiago Pericasgeertsen, <santiago.pericasgeertsen@xxxxxxxxxx> wrote:
_______________________________________________
On May 25, 2021, at 3:37 AM, Edwin Amoakwa <edwin.amoakwa@xxxxxxxxx> wrote:
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
_______________________________________________
On Sat, 22 May 2021, 9:20 am Markus Karg, <markus@xxxxxxxxxxxxxxx> wrote:
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$
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!MA_aD99DmPOWTmDlGKp0czfFsgDUl9Wq_SuproALcL3ZgxSfZrHArjbHGmVclz8$