[Geoserver-devel] Moving to servlet-api 3.0

Hi all,

To use new features in the servlet api (specifically HttpServletRequest.login to support delegating authentication from GeoServer to the container) the version would need to be bumped.

That means GeoServer won’t run on older containers like Tomcat 6 which is still supported by Apache.

Would that be an acceptable change for GeoServer?

Br,
Martin Andersson

On Wed, Nov 11, 2015 at 3:46 PM, Martin Andersson <
martin.andersson@anonymised.com> wrote:

Hi all,

To use new features in the servlet api (specifically
HttpServletRequest.login to support delegating authentication from
GeoServer to the container) the version would need to be bumped.

That means GeoServer won't run on older containers like Tomcat 6 which is
still supported by Apache.

I know of a fair number of people still running Tomcat 6 (to my surprise, I
might add).
Also, our bin/windows/osx bundles are running Jetty 6, which is really old,
but has been upgraded to version 9 on the development series only, that one
seems to support servlet 3 according to
https://en.wikipedia.org/wiki/Jetty_(web_server)

I think we can consider this as an option for the development series, but
not for stable (2.8.x) and maintenance (2.7.x).
Just my opinion though, let's hear the other devs

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

As someone who tried to do this recently I can offer some insight. The real work is updating our tests. We use a mock library (mock runner) for mocking up servlet api objects (requests, response, servlet context), etc… And I wasn’t able to upgrade to a version that supports a newer version of the servlet api spec (3.0 or 3.1). It wasn’t clear to me if mock runner is being well maintained anymore. I found a few open github issues about the topic that date back to 2013.

That said, spring has better and more up to date support for mocking those objects, so I recommend we move to that. Unfortunately that is a pretty far reaching change (albeit pretty mechanical), it’s just updating imports and then updating a few method calls that are different between mock runner and spring mock http. Basically it needs someone (or a group of people) to be gung-ho enough to go through all modules and make the updates. With some scripting / regex it might actually not be that bad but I never got that far.

$0.02

···

On Wed, Nov 11, 2015 at 7:56 AM, Andrea Aime <andrea.aime@anonymised.com…> wrote:



Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Wed, Nov 11, 2015 at 3:46 PM, Martin Andersson <martin.andersson@anonymised.com> wrote:

Hi all,

To use new features in the servlet api (specifically HttpServletRequest.login to support delegating authentication from GeoServer to the container) the version would need to be bumped.

That means GeoServer won’t run on older containers like Tomcat 6 which is still supported by Apache.

I know of a fair number of people still running Tomcat 6 (to my surprise, I might add).
Also, our bin/windows/osx bundles are running Jetty 6, which is really old, but has been upgraded to version 9 on the development series only, that one
seems to support servlet 3 according to https://en.wikipedia.org/wiki/Jetty_(web_server)

I think we can consider this as an option for the development series, but not for stable (2.8.x) and maintenance (2.7.x).
Just my opinion though, let’s hear the other devs

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


On Wed, Nov 11, 2015 at 6:20 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

That said, spring has better and more up to date support for mocking those
objects, so I recommend we move to that. Unfortunately that is a pretty far
reaching change (albeit pretty mechanical), it’s just updating imports and
then updating a few method calls that are different between mock runner and
spring mock http. Basically it needs someone (or a group of people) to be
gung-ho enough to go through all modules and make the updates. With some
scripting / regex it might actually not be that bad but I never got that
far.

Ah, I was thinking about it some time ago and had a half baked idea of
doing something like this:
* Drop mockrunner
* Implement new fresh java code in gs-main, but with the same package and
class name as the old mockrunner classes we were using
* Fill them delegating to the spring mock objects (or extending them)
* Finally tell the IDE to refactor those in a geoserver package

Sounds like it could be less work... but maybe not... I did not actually
check what would need to be done :-p

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------