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 ;) > 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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
