For the purpose of moving this forward, I have merged PR #4311 [1]. From a
runtime POV this now requires a minimum 3.0 servlet compatible container.
Documented minimum, however, is at least 3.1.
I suggest that if anyone would like to see documented newer support that
that should be proposed
To be clear, this proposal just wants to update the *minimum* *documented*
requirement. The following PR would require that to be 3.0:
https://github.com/apache/geode/pull/4311
There is no additional change required other than documentation.
--Jens
On Wed, Nov 20, 2019 at 9:46 AM Udo Kohlmeyer
I think that we should really be looking at going to 4.0.
It would be compatible with 3.1, but given that 4.0 is standard with
Java 8 (which already EOL), we should try and get onto the latest.
I don't think that us aligning ourselves with a tech release in 2013 is
something we should do.
Since there appears to be consensus, I'm going to give this thread another
24 hours and will then consider this proposal accepted.
If anyone does have concerns please do raise them now.
Thanks
--Jens
On Sat, Nov 16, 2019 at 8:17 AM Joris Melchior wrote:
> +1 for bumping to 3.1
>
> On Fri, Nov
+1 for bumping to 3.1
On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett wrote:
> +1 for 3.1
>
> > On Nov 15, 2019, at 3:08 PM, Jens Deppe wrote:
> >
> > +1 to bumping the documented support to 3.1.
> >
> > The prompting for this proposal is due to this PR which specifically
> wants
> > to
+1 for 3.1
> On Nov 15, 2019, at 3:08 PM, Jens Deppe wrote:
>
> +1 to bumping the documented support to 3.1.
>
> The prompting for this proposal is due to this PR which specifically wants
> to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
>
> Thus implementing this change
+1 to bumping the documented support to 3.1.
The prompting for this proposal is due to this PR which specifically wants
to utilize a *3.0* API: https://github.com/apache/geode/pull/4311
Thus implementing this change will not preclude being able to use the
Session Module in a 3.0 container (even
1 more thing...
You can provide additional/dedicated support for newer versions (e.g.
Servlet 4.0) without (unduly) sacrificing backwards compatibility. This is
done by many popular Java frameworks in fact, which also simultaneously
constitute a minimum baseline (e.g. Servlet 3.1). Be current
I would minimally bump it to 3.1 then. Not only does Servlet 3.1 open up
more doors (e.g. NIO), but is also implemented by all current Servlet
Container providers (Tomcat, Jetty, etc). Additionally, given all the
Servlet Containers Jens mentioned at the version that started supporting
Servlet
+1 to bumping to servlet 3.0.
-Dan
On Fri, Nov 15, 2019 at 12:16 PM Charles Smith wrote:
> Seems to me as long as newer Servlet specs do not deprecate
> functionality/api that the session module requires AND that the session
> module is not missing any important functionality provided by newer
Seems to me as long as newer Servlet specs do not deprecate functionality/api
that the session module requires AND that the session module is not missing any
important functionality provided by newer Servlet specs that it's best to base
support the oldest Servlet spec that is still supported by
Since the Servlet 3.1 spec is available and the current version is 4.0, why
not consider 3.1 or even 4.0, actually?
-j
On Fri, Nov 15, 2019 at 8:59 AM Jens Deppe wrote:
> Hello Charles; thanks very much for bringing this up.
>
> I vote +1 on this proposal.
>
> Just to add a bit more details
Hello Charles; thanks very much for bringing this up.
I vote +1 on this proposal.
Just to add a bit more details for others:
The 3.0 Servlet Spec was finalized at the end of 2009. The *earliest*
versions of various containers that supported it are:
- Jetty 8 (EOL'd since 11/2014) [1]
-
Hello,
The Geode HTTP Session Management Module for AppServers currently states:
This approach is a generic solution, which is supported by any container that
implements the Servlet 2.4 specification.
I would like to suggest that this official support be bumped up to the Servlet
3.0
14 matches
Mail list logo
