Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Over the past few works i have been working on implmenting virtual services as described by:
http://geoserver.org/display/GEOS/GSIP+44+-+Virtual+services+with+workspaces
The request:
GET http://localhost:8080/geoserver/topp/wfs?request=getcapabilities
still returns this?
<FeatureType xmlns:tiger="http://www.census.gov">
<Name>tiger:giant_polygon</Name>
...
</FeatureType>
It should not. Or I'm misunderstanding something?
Hmmm... nope it should not. I posted the patch with some bits commented out that should not have been. When the advanced dispatch flag is disabled that request should give you a 404 with a log message that there is no such mapping.
I have put together a patch here that I hope to commit soon:
http://jira.codehaus.org/browse/GEOS-3768
The patch is quite big as expected. Which begs the question is this appropriate for 2.0.x which was the branch originally targeted.
Most of the work is additive and it has been done in a way where by default it would be disabled. But it makes some substantial changes. So the question is should this work be more suitable for trunk and not the stable branch.
All that said, this work is for a customer who requires the use of GeoServer 2.0.x. So if we do decide this work is not suitable for the stable branch I could continue to maintain a branch of 2.0.x that has the changes (most likely in a git repo since maintaining branches with svn is painful) and provide the customer with releases from that branch.
Thoughts? Opinions?
The patch is really big indeed. On the bright side it seems you added
a lot of testing for it for the various services, by the looks of it
it would seem every part you modified was accompained by one or more
tests to cover it.
(which reminds me, there may be some hurdles applying it to trunk where WCS is being modified).
I have been synchronizing with trunk and resolving conflicts. I ran into a couple of things with wcs, but easily resolvable.
I see there is quite a bit of work done to
enable "advanced dispatching". Is that part necessary to get
virtual services to work? It's difficult to assess by just reading
the patch.
Well it is necessary to achieve the "geoserver/<workspace>/wfs" url structure which i believe is preferred to the "geoserver/wfs/<workspace>". However solving it did allow for the solving of the long time standing problem of not allowing people to plug in new url structures which is partly why I pushed on it.
You say that by default the new code is disabled, but looking at it
it would seem otherwise, at the very least, it seems the majority
of changes are in the main path and thus "always on"?
Can you help me understand how the various wrappers and callbacks
get disabled? The patch is big and I'm having some troubles wrapping
my head around it.
Well the advanced dispatching is enabled and disabled in web.xml. If you look at it you will see a new parameter. You will also see a commented out catch all mapping. There are some comments in the web.xml that explain.
Basically how it will work is when that flag is enabled two thigns will happen:
1. the subclass of DispatcherServlet, GeoServerDispatcherServlet will hack the servlet path. This is what allows the web ui and rest to continue to function.
2. the OWSHandlerMapping class, subclass of SimpleUrlHandlerMapping will check for an initial path component that matches a workspace, and if it does will strip it off and forward the request to the regular dispatching chain. This is the part that allows "/topp/wfs" to match the regular "/wfs" mapping.
In any case, the code I see is clean and well tested. The only concern
is how widely it affects the code base. I'm kind of +0.5 on committing
it to 2.0.x, on one side I recognize a work well done, on the other
side there is the obvious risk of making extensive changes.
Hopefully the rest of the PSC will chime in.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.