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 separately.

Thanks
--Jens

[1] - https://github.com/apache/geode/pull/4311

On Wed, Nov 20, 2019 at 10:15 AM Jens Deppe <jde...@pivotal.io> wrote:

> 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 <u...@apache.com> wrote:
>
>> 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.
>>
>> --Udo
>>
>> On 11/20/19 9:17 AM, Jens Deppe wrote:
>> > 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 <jmelch...@pivotal.io>
>> wrote:
>> >
>> >> +1 for bumping to 3.1
>> >>
>> >> On Fri, Nov 15, 2019 at 10:27 PM Jacob Barrett <jbarr...@pivotal.io>
>> >> wrote:
>> >>
>> >>> +1 for 3.1
>> >>>
>> >>>> On Nov 15, 2019, at 3:08 PM, Jens Deppe <jde...@pivotal.io> 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 will not preclude being able to use the
>> >>>> Session Module in a 3.0 container (even if we document support as
>> being
>> >>>> against 3.1)
>> >>>>
>> >>>> --Jens
>> >>>>
>> >>>>> On Fri, Nov 15, 2019 at 2:57 PM John Blum <jb...@pivotal.io> wrote:
>> >>>>>
>> >>>>> 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 3.0 are no longer supported, then 3.1 seems like a
>> >>> good/reasonable
>> >>>>> target.
>> >>>>>
>> >>>>> -j
>> >>>>>
>> >>>>>> On Fri, Nov 15, 2019 at 12:49 PM Dan Smith <dsm...@pivotal.io>
>> >> wrote:
>> >>>>>> +1 to bumping to servlet 3.0.
>> >>>>>>
>> >>>>>> -Dan
>> >>>>>>
>> >>>>>> On Fri, Nov 15, 2019 at 12:16 PM Charles Smith <
>> smith...@macewan.ca>
>> >>>>>> 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
>> >>>>>> Servlet
>> >>>>>>> specs that it's best to base support the oldest Servlet spec that
>> is
>> >>>>>> still
>> >>>>>>> supported by active container versions. As Jens nicely enumerated,
>> >>> this
>> >>>>>>> seems to be Servlet 3.0 right now.
>> >>>>>>>
>> >>>>>>> At least that's the approach that would give the session
>> management
>> >>>>>>> modules the widest audience. I am currently writing a Servlet 4.0
>> >> web
>> >>>>> app
>> >>>>>>> and the Geode session module is working great except that I need
>> to
>> >>>>> layer
>> >>>>>>> on an additional filter to ensure my session cookies are secure.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>>
>> >>>>>>> Charles Smith
>> >>>>>>>
>> >>>>>>> Developer/Analyst
>> >>>>>>>
>> >>>>>>> Web Architecture and Development
>> >>>>>>> MacEwan University
>> >>>>>>> smith...@macewan.ca
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> ________________________________
>> >>>>>>> From: John Blum <jb...@pivotal.io>
>> >>>>>>> Sent: Friday, November 15, 2019 11:17 AM
>> >>>>>>> To: geode <dev@geode.apache.org>
>> >>>>>>> Subject: Re: Proposal to modify Servlet spec support for the HTTP
>> >>>>> Session
>> >>>>>>> Management Module for AppServers
>> >>>>>>>
>> >>>>>>> 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 <jde...@pivotal.io>
>> >> wrote:
>> >>>>>>>> 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]
>> >>>>>>>>    - Tomcat 7 (Version 6 EOL'd 2017) [2]
>> >>>>>>>>    - JBoss Web 3.0.0 (version 2.x reached End of Maintenance
>> >> 11/2017)
>> >>>>>> [3]
>> >>>>>>>>    - Websphere 8.0 (End of support 4/2018) [4]
>> >>>>>>>>    - Weblogic 12cR1 (Extended Support until 12/2019) [5]
>> >>>>>>>>
>> >>>>>>>> The implication is that, of these products, there are *no*
>> >> currently
>> >>>>>>>> supported versions that *do not* support the Servlet 3.0 spec. I
>> >>>>>> believe
>> >>>>>>> it
>> >>>>>>>> is quite safe for us to indicate that the Session Modules are now
>> >>>>> only
>> >>>>>>>> supported on 3.0 compliant containers.
>> >>>>>>>>
>> >>>>>>>> --Jens
>> >>>>>>>>
>> >>>>>>>> [1] -
>> >>>>>>>>
>> >>
>> https://www.eclipse.org/jetty/documentation/current/what-jetty-version.html
>> >>>>>>>> [2] - http://tomcat.apache.org/whichversion.html
>> >>>>>>>> [3] -
>> https://access.redhat.com/support/policy/updates/jboss_notes
>> >>>>>>>> [4] -
>> >> https://en.wikipedia.org/wiki/IBM_WebSphere_Application_Server
>> >>>>>>>> [5] -
>> >>>>>>>>
>> >>>>>>>>
>> >>
>> https://www.solstice.com/fwd/survival-guide-to-webspheres-and-weblogics-end-of-life
>> >>>>>>>> On Fri, Nov 15, 2019 at 8:11 AM Charles Smith <
>> smith...@macewan.ca
>> >>>>>>> wrote:
>> >>>>>>>>> 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 specification.
>> >>>>>>>>>
>> >>>>>>>>> There are some important cookie security features missing in the
>> >>>>>>> ancient
>> >>>>>>>>> Servlet 2.4 spec, namely the secure and httpOnly flags. Bumping
>> >>>>>> support
>> >>>>>>>> to
>> >>>>>>>>> Servlet 3.0 would allow the Geode AppServer session module to
>> >>>>>>> inherently
>> >>>>>>>>> support these session cookie security features.
>> >>>>>>>>>
>> >>>>>>>>> I have logged the following Jira issue:
>> >>>>>>>>>
>> >>>>>>>>> https://issues.apache.org/jira/browse/GEODE-7438
>> >>>>>>>>>
>> >>>>>>>>> and submitted a pull request that provides the necessary support
>> >> if
>> >>>>>> the
>> >>>>>>>>> Geode community agrees this is a good idea.
>> >>>>>>>>>
>> >>>>>>>>> And thank you for the excellent Apache Geode project!
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>>
>> >>>>>>>>> Charles Smith
>> >>>>>>>>>
>> >>>>>>>>> Developer/Analyst
>> >>>>>>>>>
>> >>>>>>>>> Web Architecture and Development
>> >>>>>>>>> MacEwan University
>> >>>>>>>>> smith...@macewan.ca
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> -John
>> >>>>>>> john.blum10101 (skype)
>> >>>>>>>
>> >>>>>
>> >>>>> --
>> >>>>> -John
>> >>>>> john.blum10101 (skype)
>> >>>>>
>> >>
>> >> --
>> >> *Joris Melchior *
>> >> CF Engineering
>> >> Pivotal Toronto
>> >> 416 877 5427
>> >>
>> >> “Programs must be written for people to read, and only incidentally for
>> >> machines to execute.” – *Hal Abelson*
>> >> <https://en.wikipedia.org/wiki/Hal_Abelson>
>> >>
>>
>

Reply via email to