| Re: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10? |
On Mon, 31 Aug 2020 at 02:58, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Yes, the first step in the feasibility study should include gauging what the appetite is from JAX-RS. Of course at least one team member is interested in it, but we'd need some general consensus. I'd roughly imagine this Servlet lite, or HTTP Core to provide an API to Netty, Grizzly, Coyote, etc.Do we really want another user facing HTTP API? If there are shortcomings in JAX-RS I think we should look at fixing these, rather than creating a new API.
JAX-RS is not just for restful endpoints, you can handle HTTP requests any way you like.
To be honest I don't really see how this will differentiate itself for JAX-RS, do you have any examples or use cases where this new API will be substantially better than JAX-RS?Stuart______________________________Kind regards,Arjan______________________________Reza RahmanJakarta EE Ambassador, Author, Blogger, SpeakerPlease note views expressed here are my own as an individual community member and do not reflect the views of my employer.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: arjan tijms <arjan.tijms@xxxxxxxxx>Date: 8/30/20 11:31 AM (GMT-05:00)To: servlet developer discussions <servlet-dev@xxxxxxxxxxx>Subject: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10?Hi,On Sun, Aug 30, 2020 at 4:45 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:While I certainly appreciate the idea of aligning more Jakarta EE specifications to CDI, who would really be the target audience for a CDI based Servlet component model? Wouldn't this audience in practice have a lot of overlap with JAX-RS users? If so, is this an effort worth undertaking? Maybe this is something best pursued as an experimental framework to see what the uptake would be instead of work done in Jakarta?I'm certainly willing to attempt it as an experimental framework first. You're right that there's a bit of an overlap with JAX-RS, though that has always been the case to some degree.The audience would essentially be people taking advantage of all the traditional use cases for Servlet; handling requests which are not essentially restful in nature, and serving data accordingly. The added value would the extra flexibility to apply interceptors and scopes. Meaning that one can install e.g. an HTTPAuthenticationMechanism, and apply the more advanced security interceptor that we're planning for Jakarta Security 3.It's for that reason I proposed not adding any fancy features. It are Servlets, but re-imagined as beans.Another, perhaps even more important reason for this is to have a place to put the CDI based producers (Bean<T>s really), which are now in CDI core, to inject instances like the current HttpServletRequest. Those are in need of some overhaul (e.g, it's not at all defined which *current* HTTPServletRequest is injected, think original, vs wrapped, vs one after an include or forward etc). The CDI spec has indicated those things never belonged in CDI. CDI is to be used as a foundation for other specs, not as a Facade for Servlet and others.Now we attempted to move these things to Servlet, but that failed. Jetty is not specifically interested in CDI (reiterated here above), and that's what it is. It's their right to have that opinion. We discussed it before, had different opinions, but eventually resolved the discussion.So instead of repeating all those discussions, this new (small) CDI sub-spec / related standalone spec could conveniently contain all the CDI producers for Servlet types, and perhaps (if there's interest) CDI versions of Servlet events.Personally I think it is important to try to align JAX-RS and Servlet if it is not too late to do so.JAX-RS seems unfortunately not interested in re-basing on full Servlet, even though in practice nearly all JAX-RS implementations are Servlet based. The core HTTP library discussed here should be able to stand a chance though, and that would be a good step.A related area to perhaps think about is making Servlet more Reactive. Although even in this space I am not sure what the practical uptake has been, if there has been sufficient maturity and what the impact of Project Loom will be.What is slam dunk for me is working on the existing backlog of more minor enhancements including keeping track of HTTP/3.Yes, indeed.I think an API to reduce the need for frameworks to do annotation scanning would also be invaluable and overdue. This is potentially even something that could go into Java SE. I do think this is an API that should be separate from Servlet and usable in applications that may not be Servlet based.Absolutely!Kind regards,Arjan Tijms______________________________Reza RahmanJakarta EE Ambassador, Author, Blogger, SpeakerPlease note views expressed here are my own as an individual community member and do not reflect the views of my employer.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: arjan tijms <arjan.tijms@xxxxxxxxx>Date: 8/27/20 7:53 AM (GMT-05:00)To: servlet developer discussions <servlet-dev@xxxxxxxxxxx>Subject: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10?Hi,A number of other specs in Jakarta have provided some ideas or roadmap items for their next major versions.Until so far I don't think Servlet has provided any such ideas, although we do have a backlog of about 112 issues, which are mostly clarifications or small enhancements.One of the pitched themes for Jakarta EE 10 is alignment, and for this theme I'd like to make a few proposals:1. In cooperation with Jakarta REST (previously JAX-RS), see if we can define a subset of Servlet on which Jakarta REST can conveniently depend. At the moment most Jakarta REST implementations are based on Servlet anyway, but officially there's no such dependency.2. For in a Jakarta EE environment, and as a separate related new spec, define a CDI version of Servlet, for instance with the proposed package jakarta.servlet.cdi. This would define what a Servlet would look like as a pure CDI bean, and in addition would finally allow us to transfer the HttpServletRequest producer that's now in core CDI itself.Alternatively this can also be proposed as a completely independent spec, not using the jakarta.servlet package, and just building on Servlet (like, e.g. Jakarta Faces does).Thoughts?Anything else that's big? Any of the existing issues we'd like to prioritize for Servlet 6?Kind regards,Arjan Tijms_________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
_________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev