> Wow, the patch looks... big! :) > At a quick look the size is due to some changes to the EMF models > that now have a "provided version", and then I see changes in the > response class hierarchies... could you very quickly summarize what > you did so that we can orientate in the new code structure? > Like in a bulleted list of short statements, something that gives > a feel of the change. No need to be fancy :) Apologies i should have gave a better description in my original mail :) . Here it is.
The first thing i did was moved all the wfs 1.1 specific beans to a different application context. I also moved all the wfs 1.1 specific tests overt as well since they no longer pass due to lack of the 1.1 context around. That was the easy part. Taking the new wfs11 module off the classpath i found that still 1.1 requests were being returned in cases where the version was not specified. There are a couple of checks in the code which fall back on 1.1 version when no version is specified. Instead of this hard coded check i added a list of Version to WebFeatureService. Now the version negotiation stuff actually looks for Service versions in the context and defaults to the highest, rather than hardcoding 1.1. The other problem I had was access flipping. As you know there is the WFSProjectionUtil class which does access flipping in a wfs 1.1 request. So even though wfs11 is not enabled unless the client specifies version=1.0.0 they get things flipped. At first I tried to get the request readers to just set the version on the request object. However this lead to cite failures since in cases where the version is not specified we need to perserve the unset value until after the reqeust reading phase. So what I did was add a new property to the wfs model (BaseRequestType) called 'providedVersion'. And what this property is the the version of the service handling the request, which may be different than the version specified by the client. THis property is set by teh dispatcher similar to how "baseUrl" is set. I then changed all calls to WFSPRojectionUtil.getDeclaredCRS() to use providedVersion rather than version. Ad it worked!! :). > Yeah, I agree this seems like a better approach. I guess this could > be done in the dispacher no? In the dispatcher you already determine > the service and version, so if you have the list of enabled services > _and_ enabled versions you "just" have to perform a comparison, > and if the version is missing, just assume the highest enabled version? Indeed, and now that is how the providedVersion is set. The problem is i like the separation now of the dispatcher as it does not rely on the configuration. Having to load a services configuration object from the dispatcher will make it quite a bit messier. I am sure there is a way around it... we could add some sort of extension point (similar to transaction) to the dispatcher and add a check which matches us providedVersion and ensures that the ServiceInfo.getVersion() says that service is enabled... not sure. > 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://sourceforge.net/services/buy/index.php > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > !DSPAM:4007,48649ae3224588992556831! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
