Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Less is More for servlet 6.0


What will the process for hacking out features from the servlet specification look like, would that ultimately have to go to the JakartaEE Platform for some sort of approval or at discussion amongst other specs? I try to make that call most weeks and would be happy to add that to the agenda for the next call (ie, hear what they think that feature removal process should look like). Let me know.

There is a lot of discussion around a new 'Core' Profile that would include servlet and then maybe a spec or two above, obsentiably handle web services and the like.  It might make sense to view a Servlet 6 in the context of that.

Anyway, exciting!
Jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, Apr 15, 2021 at 9:55 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

It's a long post, and I haven't read it in detail either, but at a glance I like the overall tone of it. I'd especially like to see the cross-context feature go.

On that, there's still a TCK test around that concept that I think should be challenged (getContext() is allowed to return a null, but there's a TCK test that assumes it's never null).

Kind regards,
Arjan Tijms










On Thu, Apr 15, 2021 at 12:41 PM Mark Thomas <markt@xxxxxxxxxx> wrote:
On 13/04/2021 07:27, Greg Wilkins wrote:
>
> All,
>
> I've just published a blog called Less is More
> <https://webtide.com/less-is-more-servlet-api/> where I make the
> argument that we need to remove and/or deprecate several features in the
> servlet specification for 6.0, so that we can clear the decks for new
> features.
>
> I won't repeat the blog here (it's rather long), but as discussion of
> the spec should be here, I will direct commenters to this thread.

I haven't had a chance to review the article in detail so I'll just say
I think there is going to be quite a bit of discussion around exactly
what should be removed and what should stay.

I need to get a draft release plan submitted today for the next
development iteration so I am going to submit one for a major release
(6.0) rather than a minor release (5.1) on the basis that whatever we do
I am fairly sure we are going to want to make backwards incompatible API
changes. Whether that is as little as removing the code that has been
deprecated for well over a decade or as much as Greg is advocating for
is very much TBD but we have time to discuss that.

I'm going to keep the plan very high level. Essentially:
- remove deprecated features
- consider removing / deprecating additional features
- add clarify to existing features
- implement requested enhancements

Prioritisation to be determined by the community as work progresses.

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

Back to the top