Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] New features in EE9 for Servlet-API 5.0?



Note that Chrome will soon start ignoring cookies without Same-Site set: https://www.chromestatus.com/feature/5088147346030592
This puts a different perspective on the need to support Same-Site cookies.

Unfortunately because we cannot update the javax versions, this means that most containers will need to support this feature with proprietary configuration.   If we cannot add it in EE9, then there will be no standard based container that will work with the most common browser.   I hope EE10 comes out ASAP!

regards











On Mon, 20 Jan 2020 at 16:56, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
If most other projects are making their EE9 release a rename only release, then I think that servlet-api should follow and not try to be special.   

However, it will be a hassle for vendors managing releases for 4.0, 5.0 and 5.1... but probably down among the noise against the whole hassle of the rename anyway :(

cheers


On Mon, 20 Jan 2020 at 08:16, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Dear ee spec group.

The servlet-api project is trying to come up with our project plan for our 5.0 and 5.1 releases.

The 5.0 release will be our javax->jakarta rename release and the key question we have is can we also put some new features into that release?  Or does it have to be exactly like 4.0, but with only the name changed?

There are some minor features that we really need to add to stay relevant to current browser and specifications.  A key example is sime-site cookie support as proposed in https://github.com/eclipse-ee4j/servlet-api/pull/271 and the matching schema change https://github.com/eclipse-ee4j/jakartaee-schemas/pull/1

If changes like these cannot be in a 5.0, then we will need a 5.1 as soon as possible after 5.0.

I understand that have a pure renaming release would give some degrees of simplicity when porting,  but I'm not sure that helps much if soon afterwards we have to deal with demand for 5.1

Thus our question is - can we make some minimal additions to the API in 5.0 on the basis that they will be reviewed against the criteria of not hindering any automated porting tools of 4.0 to 5.0?

regards












--


--


--

Back to the top