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.
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 think if we can avoid introducing the concept of workspace into gwc it would probably be a good idea. But I am not sure if it will be possible for gwc to pass the first part of the uri path through without having to make assumptions about its structure. -Justin On 3/1/10 1:41 PM, Andrea Aime wrote: > Hi, > GWC integration on trunk is not working anymore as a result > of the mini resource/publish split changes. I want to fix this, > but I think I need some context on the how. > > The issue happens when GWC calls onto WMS via the dispatcher, > as GWC is building a fake servlet enviroment in which the dispatcher > works and the following exception is thrown: > > at > org.geowebcache.layer.wms.FakeHttpServletRequest.getRequestURI(FakeHttpServletRequest.java:112) > at org.geoserver.ows.Dispatcher.init(Dispatcher.java:293) > at > org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:207) > at > org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) > at org.geoserver.ows.Dispatcher.handleRequest(Dispatcher.java:50001) > at > org.geowebcache.layer.wms.WMSGeoServerHelper.makeRequest(WMSGeoServerHelper.java:35) > at > org.geowebcache.layer.wms.WMSSourceHelper.makeRequest(WMSSourceHelper.java:62) > at > org.geowebcache.layer.wms.WMSGeoServerHelper.makeRequest(WMSGeoServerHelper.java:50001) > > This happens as the dispatcher runs these lines: > > // parse the request path into two components. (1) the 'path' which > // is the string after the last '/', and the 'context' which is > the > // string before the last '/' > String ctxPath = request.httpRequest.getContextPath(); > String reqPath = request.httpRequest.getRequestURI(); > reqPath = reqPath.substring(ctxPath.length()); > > Now, those are used to get the context and, I guess, to decide what > layers are visible eventually? > GWC FakeHttpServletRequst is throwing an exception when getContextURI() > is called, and fixing it is easy, the real question is, what is the > appropriate return value? > > GWC does not have the concept of workspaces, so when a request > comes in, what happens? Should GWC build a fake request that does not > have a workspace in it? However, how that will affect the GWC ability to > play with a GeoServer that actively uses workspaces for access control? > Or should the GWC integration somehow mirror OWS services workspaces > behavior? > > 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
