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.
> > I'm not even sure that GWC, as a stand alone app, should be concerned > about that at all. > > Rough idea: register in the GeoServer integration a wrapper around > the GWC own dispatcher that: > - checks global services are on, and eventually refuses to answer > the request if the workspace is not there > - strips the workspace from the URL before it reaches GWC, and stores > it in a thread local One thing to note is that there is already a thread local workspace variable available called LocalWorkspace which can be used if need be. I am however not sure how the ows dispatcher callback that sets this variable will play with this if it is already set. I assume it probably just blindly overwrites it. > - makes the GWC->WMS direct path grab the workspace and reintegrate it > into the request by using the indirections provided by > FakeHttpServletRequest > > How does this sound? Should not be much work and I'd rather do it sooner > instead of later. 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. - have the dispatcher preserve any initial parts of the request path so that it can properly create the hake http request with the workspace prefix Now of course this does not handle the case in which gwc should not respond if global services are turned off. So some sort of check (in a wrapper) will be needed. > > One thing that would remain unchanged is the GWC demo page, which would > keep on listing all of the layers no matter what. Not sure we > can do anything about it unless GWC add a concept of layer filtering > that we can plug into. > > 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
