On 3/2/10 8:52 AM, Andrea Aime wrote: > Justin Deoliveira ha scritto: >> On 3/2/10 6:38 AM, Andrea Aime wrote: >>> Justin Deoliveira ha scritto: >>>> Interesting... and indeed something I did not take into account when >>>> doing the virtual service work. Shame on me for not testing gwc and >>>> shame on all of us for not having better gwc test coverage. >>> >>> Well, let's fix it. >>> >>>> That said, if we consider gwc another type of service it probably >>>> makes sense to have it fall under the virtual service banner, and >>>> something that could be restricted to workspace. But for the time >>>> being it is considered something global and afaik something the will >>>> be affected even if the user decides to disable global services. >>>> >>>> I would say in the short term simply set the parameter and ensure that >>>> gwc does not assume any particular uri structure. But as you say as >>>> soon as someone disables the global wms... boom! >>>> >>>> In the medium term we should wrap gwc in the virtual service goodness. >>>> The first step to doing this is to use a OWSUrlHandlerMapping instead >>>> of the spring SimpleUrlHandlerMapping one for the dispatcher mapping. >>>> And then it is just a matter of following a request down and see where >>>> things fail, patch any reflective urls so they include the specified >>>> workspace, etc... >>> >>> I tried to look into this directly. >>> The main issue I see is that GWC would have to become aware of the >>> workspaces. Atm the GeoWebCacheDispatcher (part of the GWC code) >>> receives a request like: >>> >>> http://localhost:8080/geoserver/nurc/gwc/demo/nurc:Arc_Sample?gridSet=EPSG:900913&format=image/png >>> >>> >>> >>> and returns complaining it does not know what /nurc/ is. >> Just to clarify the gwc dispatcher never gets hit right? The spring >> dispatcher should return a 404 in this case. > > Sorry, I actually tried to use the OWSHandlerMapping so the > gwc dispatcher was being hit, but did not know what to make > of the incoming request due to /nurc/ being in the path > > That's why I was talking about having to strip it out and so on. > >> I am still not really sure it is necessary to have gwc know about >> workspaces but I could be wrong here. The approach I would try is this: >> >> - make the gwc dispatcher mapping an OwsUrlHandlerMapping so that it >> can handle url's of the form /nurc/gwc/** >> >> - have the gwc dispatcher do its parsing of the request path in a more >> lax way. Rather than assuming a particular path structure just pop >> path components off the end of the path as need be. > > We can try, it's a matter of knowing where the actual path starts. > Be too lax and we might start reporting back strange error messages > when the user makes invalid requests, or even valid requests > in corner cases. > Point in case, what happens if in GeoServer there is a workspace > called gwc, for example? Or one called services, wms, wmts, or > any other of the normal urls GWC parses? > Fair enough. This is an issue with virtual services in general. There is probably a way to trick the system into giving you a misleading error or have it dispatch an improper request when global services are turned off.
I don't think it is unreasonable to tell users to simply "don't do that". If we really want to enforce it we could set up catalog validation constraints to prevent such names from being specified. > Cheers > Andrea > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
