[Geoserver-devel] dynamic servlet mappings... a long sad tale

GeoServer GeoServer Developer
1

Hi all,

I spent a few hours this evening trying relieve us of the burden of having to register the mapping to the spring dispatcher servlet in web.xml every time we add a new service. The blocker before was that the routing from spring to struts was not working correctly. I managed to fix this problem... I think it may just be the upgrade to spring 2 that fixed it though.

Anyways, excited at this point I continued on and registered a single mapping to the spring dispatcher servlet, and kept all the service mappings in the applicationContext.xml files for each module. However this reared another ugly problem handling jsp's.

The short of it is that a "catch all" mapping overrides all the internal mappings that the servlet container uses. Or at least it does for Jetty. So what happens is that a request for .jsp files instead of going to the jsp compiler go to the spring dispatcher which coughs up a 404 naturally.

So... this leaves us where we started :(. I can think of perhaps a couple of ways to get around this... none particularly ideal though:

1. Always place services under a sub context path:

This would involve creating "sub contexts" for everything (similar to what we do with the ows mapping today):

/geoserver/ows -> OWS style services
/geoserver/rest -> REST apis
/geoserver/ui -> user interface

2. Choose a UI framework that does not jsp

This would cut down the ui list drastically. Although Wicket which is a top contender would still be in running. Perhaps this along with modular UI will make Wicket unbeatable.

I also think that Spring's MVC stuff would allow us to work around this.

3. Run the administration web app separate from geoserver services themselves.

The downside here is that all interaction with geoserver would have to be remote. Which has been done before by other apps so is definitely doable. It could also be a driver for a REST/Javascript based UI.

I do think it might be interesting to have the UI be able to remotely admin a Geoserver on a different machine. Could be useful for someone administrating a cluser of remote machines... I don't know.

4. Compile JSP files manually

I tried this one... registering the jasper compiler to handle .jsp mappings. It failed though and I did not take it much further.

Anyways... some ideas, not sure if any of them are good :). Feedback and comments welcome.

-Justin

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

2

Justin Deoliveira ha scritto:

Hi all,

I spent a few hours this evening trying relieve us of the burden of having to register the mapping to the spring dispatcher servlet in web.xml every time we add a new service. The blocker before was that the routing from spring to struts was not working correctly. I managed to fix this problem... I think it may just be the upgrade to spring 2 that fixed it though.

Anyways, excited at this point I continued on and registered a single mapping to the spring dispatcher servlet, and kept all the service mappings in the applicationContext.xml files for each module. However this reared another ugly problem handling jsp's.

The short of it is that a "catch all" mapping overrides all the internal mappings that the servlet container uses. Or at least it does for Jetty. So what happens is that a request for .jsp files instead of going to the jsp compiler go to the spring dispatcher which coughs up a 404 naturally.

Ugh....

So... this leaves us where we started :(. I can think of perhaps a couple of ways to get around this... none particularly ideal though:

1. Always place services under a sub context path:

This would involve creating "sub contexts" for everything (similar to what we do with the ows mapping today):

/geoserver/ows -> OWS style services
/geoserver/rest -> REST apis
/geoserver/ui -> user interface

Thi would make paths a bit longer, but I like the organisation

2. Choose a UI framework that does not jsp

This would cut down the ui list drastically. Although Wicket which is a top contender would still be in running. Perhaps this along with modular UI will make Wicket unbeatable.

I also think that Spring's MVC stuff would allow us to work around this.

If you just want to get rid of JPSs, you can add to the list Spring MVC + fm templates, Struts2 + fm templates, GWT, JSF + facelets, Tapestry... the list of jsp haters grows every day :wink:

3. Run the administration web app separate from geoserver services themselves.

The downside here is that all interaction with geoserver would have to be remote. Which has been done before by other apps so is definitely doable. It could also be a driver for a REST/Javascript based UI.

I do think it might be interesting to have the UI be able to remotely admin a Geoserver on a different machine. Could be useful for someone administrating a cluser of remote machines... I don't know.

I have the impression this would make development harder. When developing a new configuration, if first try to make the services work,
then do the ui, discover some issue in the rest backend, fix it, go
back... you end up debugging two applications into two separate VM...
doable, but not so nice imho.

Thouhgt, I see the interest in having a central UI that acts as a sort of KVM (http://en.wikipedia.org/wiki/KVM_switch) to multiple GeoServer installs, not for the cluster case, where you want some script/clustering middleware that keeps all nodes in synch, but in the
case where you have multiple geoservers doing different things.
The latter case it's something I'd like to address allowing a single
GeoServer to run multiple data dirs thought.

4. Compile JSP files manually

I tried this one... registering the jasper compiler to handle .jsp mappings. It failed though and I did not take it much further.

Anyways... some ideas, not sure if any of them are good :). Feedback and comments welcome.

I know I did not offer much of a solution... we also have that
italian dev group that expressed interest in redoing the GeoServer UI
in JSF (they contacted us yesterday on IRC), I asked them to share their ideas on this ml, we'll see what comes up.

Cheers
Andrea

3

Andrea Aime wrote:

we also have that
italian dev group that expressed interest in redoing the GeoServer UI
in JSF (they contacted us yesterday on IRC), I asked them to share their ideas on this ml, we'll see what comes up.

Which reminds me I have still to finalize my example based on Cocoon :frowning: ...it's not that far though.

Moreover, I gave the example a larger scope than originally planned.

Regards,

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

4

1. Always place services under a sub context path:

This would involve creating "sub contexts" for everything (similar to what we do with the ows mapping today):

/geoserver/ows -> OWS style services
/geoserver/rest -> REST apis
/geoserver/ui -> user interface

Thi would make paths a bit longer, but I like the organisation

yeah i dont mind the organization myself... the extra bit of path info is a bit of a pain... having something like /geoserver/rest/features/... might seem a bit strange. But i could go for it.

2. Choose a UI framework that does not jsp

This would cut down the ui list drastically. Although Wicket which is a top contender would still be in running. Perhaps this along with modular UI will make Wicket unbeatable.

I also think that Spring's MVC stuff would allow us to work around this.

If you just want to get rid of JPSs, you can add to the list Spring MVC + fm templates, Struts2 + fm templates, GWT, JSF + facelets, Tapestry... the list of jsp haters grows every day :wink:

Yeah...although I think any ui that goes back to the web server to load any resources, say html files... the same problem would occur.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

5

Justin Deoliveira ha scritto:

1. Always place services under a sub context path:

This would involve creating "sub contexts" for everything (similar to what we do with the ows mapping today):

/geoserver/ows -> OWS style services
/geoserver/rest -> REST apis
/geoserver/ui -> user interface

Thi would make paths a bit longer, but I like the organisation

yeah i dont mind the organization myself... the extra bit of path info is a bit of a pain... having something like /geoserver/rest/features/... might seem a bit strange. But i could go for it.

That's what happening today with the rest module extension point,
so for example in the project I'm developing we have
/geoserver/rest/csv/
/geoserver/rest/sldservice
roots for the csv and sldservice REST services roots.

2. Choose a UI framework that does not jsp

This would cut down the ui list drastically. Although Wicket which is a top contender would still be in running. Perhaps this along with modular UI will make Wicket unbeatable.

I also think that Spring's MVC stuff would allow us to work around this.

If you just want to get rid of JPSs, you can add to the list Spring MVC + fm templates, Struts2 + fm templates, GWT, JSF + facelets, Tapestry... the list of jsp haters grows every day :wink:

Yeah...although I think any ui that goes back to the web server to load any resources, say html files... the same problem would occur.

We can do the same as with the file publisher and have the dispatcher
serve stuff out of the classpath or redirect it to serve stuff from the
web application dir (that is, do what the web server would have done).
It's a must in a modular UI hypothesis, but if we don't go there,
then it's probably a big ugly.

Cheers
Andrea