Hi list,
Does anyone have any idea to walk around this unsolved annoying bug reported long time ago? It still affects the latest v2.6.2.
"Description
Reason being that the internal XSDSchemas are built from types in a single workspace, but cached globally. So to reproduce make a GML 3.1 request (via a virtual service endpoint) and then make another request that involves a type not that in that workspace (through a virtual service or global)"
You can easily reproduce it, first fire a request to workspace ‘tiger’, you will get normal output in GML3
then, if you fire any request to a different workspace, for example ‘sf’, boom! the namespace part will become ‘null’
http://localhost:8080/geoserver/sf/ows?service=wfs&version=1.1.0&request=GetFeature&typeName=sf:roads&MaxFeatures=1[http://localhost:8080/geoserver/sf/ows?service=wfs&version=1.1.0&request=GetFeature&typeName=sf:roads&MaxFeatures=1](http://localhost:8080/geoserver/sf/ows?service=wfs&version=1.1.0&request=GetFeature&typeName=sf:roads&MaxFeatures=1)
Based on my testing, I believe this is also something related to the “Resource Cache” in geoserver. For example, once you clean the cache, you have a chance the correct one previous “null” workspace layer, but at the same time the other layers will become broken - they will become ‘null’ workspace in the output.
If change to GML2 or wfs 1.0.0, this bug will not appear. But our application has to use GML3 via wfs 1.1.0.
Odd indeed! Any suggestions or hints are much appreciated!
Heaps of thanks!
Cheers,
Benny
University of Melbourne