Hi everybody.
Today I encountered a strange behaviour in geoserver wfs, when used with workspace prefix in the request (/geoserver//wfs).
In my configuration I have two workspaces, one for online data and one for test data.
They contain the same layers, styles and groups, they only have a different workspace name and url.
Everything seems to be working well with WMS, I can switch from online to test configurations, simply using a different workspace in the requests.
With WFS, instead it seems that no “per workspace” filter is applied to requests, so for a GetFeature request a typeName can’t be resolved if the namespace is not specified and the catalog contains more layers with the same local name.
I tried to look at the code to understand if this can be fixed easily and this is what I found:
- the typeName is parsed in TypeNameKvpParser and if it have no namespace a call to catalog.getFeatureTypeByName is done to retrieve one.
- this is handled by LocalWorkspaceCatalog, which should automatically resolve namespace when a workspace is specified in the request, and this is correctly done for many methods, but not for getFeatureTypeByName
- I tried to override getFeatureTypeByName to give it a behaviour similar to getLayerByName, but with no luck, since it seems that the ThreadLocal property with the request workspace is set AFTER the typeName parameter is parsed, so there’s no workspace info when I need it
Is this a known wfs limitation? Have you got any idea on a simple solution for it?
Thanks.
Mauro Bartolomeoli
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Hi Mauro,
I can’t think of a reason it shouldn’t work. If you look at the WFSWorkspaceQualifier class, it is an ows callback that is responsible for intercepting a WFS request and qualifying the name based on the local workspace being accessed. My guess is that it is probably not handling this case for some reason. I would put a breakpoint there and see what it is doing.
-Justin
···
On Tue, Mar 5, 2013 at 11:04 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
Hi everybody.
Today I encountered a strange behaviour in geoserver wfs, when used with workspace prefix in the request (/geoserver//wfs).
In my configuration I have two workspaces, one for online data and one for test data.
They contain the same layers, styles and groups, they only have a different workspace name and url.
Everything seems to be working well with WMS, I can switch from online to test configurations, simply using a different workspace in the requests.
With WFS, instead it seems that no “per workspace” filter is applied to requests, so for a GetFeature request a typeName can’t be resolved if the namespace is not specified and the catalog contains more layers with the same local name.
I tried to look at the code to understand if this can be fixed easily and this is what I found:
- the typeName is parsed in TypeNameKvpParser and if it have no namespace a call to catalog.getFeatureTypeByName is done to retrieve one.
- this is handled by LocalWorkspaceCatalog, which should automatically resolve namespace when a workspace is specified in the request, and this is correctly done for many methods, but not for getFeatureTypeByName
- I tried to override getFeatureTypeByName to give it a behaviour similar to getLayerByName, but with no luck, since it seems that the ThreadLocal property with the request workspace is set AFTER the typeName parameter is parsed, so there’s no workspace info when I need it
Is this a known wfs limitation? Have you got any idea on a simple solution for it?
Thanks.
Mauro Bartolomeoli
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Could I just give a +1 for workspace-filtered WFS? We have similar setup. We also have datasets that we are happy for people to download (WFS + outputShapefile), and other that dont...
Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.
2013/3/5 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I can't think of a reason it shouldn't work. If you look at the
WFSWorkspaceQualifier class, it is an ows callback that is responsible for
intercepting a WFS request and qualifying the name based on the local
workspace being accessed. My guess is that it is probably not handling
this case for some reason. I would put a breakpoint there and see what it
is doing.
Hi Justin, I investigated a little bit more on this issue, and this is what
I found: unfortunately, when request parameters are specified on the url,
some checks on typeName are done before WFSWorkspaceQualifier can do it's
job of appending a namespace to unqualified names. This doesn't happen if
an XML POST is done.
The checks preventing WFSWorkspaceQualifier to do it's job are done in
TypeNameKvpParser.parseToken and GetFeatureKvpRequestReader.checkTypeName.
Do you think we could avoid or move those checks forward in the chain to
not block requests before WFSWorkspaceQualifier has done its job?
I did some manual tests and disabling those checks did the trick for my use
case, and it broke just one test (the test was expecting the parseToken
error string which is different from the error thrown during request
execution).
Anyone has an opinion on this? I can try to produce a patch if it's ok to
go this way.
Thanks.
Mauro Bartolomeoli
--
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hi Mauro,
I see. Well one potential fix would be to have the WFSWorkspaceQualifier hack the kvp map before it is parsed by the kvp readers.
Actually if you look at the class there is an empty implementation of this method.
protected void qualifyRequest(WorkspaceInfo workspace, LayerInfo layer, Service service, Request request)
That method should be called before the kvp parsers execute, and you should have access to the kvp map through the Request object.
-Justin
···
On Thu, Mar 14, 2013 at 11:00 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/3/5 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I can’t think of a reason it shouldn’t work. If you look at the WFSWorkspaceQualifier class, it is an ows callback that is responsible for intercepting a WFS request and qualifying the name based on the local workspace being accessed. My guess is that it is probably not handling this case for some reason. I would put a breakpoint there and see what it is doing.
Hi Justin, I investigated a little bit more on this issue, and this is what I found: unfortunately, when request parameters are specified on the url, some checks on typeName are done before WFSWorkspaceQualifier can do it’s job of appending a namespace to unqualified names. This doesn’t happen if an XML POST is done.
The checks preventing WFSWorkspaceQualifier to do it’s job are done in TypeNameKvpParser.parseToken and GetFeatureKvpRequestReader.checkTypeName.
Do you think we could avoid or move those checks forward in the chain to not block requests before WFSWorkspaceQualifier has done its job?
I did some manual tests and disabling those checks did the trick for my use case, and it broke just one test (the test was expecting the parseToken error string which is different from the error thrown during request execution).
Anyone has an opinion on this? I can try to produce a patch if it’s ok to go this way.
Thanks.
Mauro Bartolomeoli
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
2013/3/15 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I see. Well one potential fix would be to have the WFSWorkspaceQualifier
hack the kvp map before it is parsed by the kvp readers.
Actually if you look at the class there is an empty implementation of this
method.
protected void qualifyRequest(WorkspaceInfo workspace, LayerInfo layer,
Service service, Request request)
That method should be called before the kvp parsers execute, and you
should have access to the kvp map through the Request object.
Fine. I'll take a look at that.
Thanks
Mauro
--
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hi,
I finally found some time to craft a patch for this: https://github.com/mbarto/geoserver/commit/bd17a64ddac77b9f74c9f74b92ad9fefb3977938
If someone has some and could kindly do a review…
Thanks
Mauro Bartolomeoli
···
2013/3/15 Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com>
2013/3/15 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I see. Well one potential fix would be to have the WFSWorkspaceQualifier hack the kvp map before it is parsed by the kvp readers.
Actually if you look at the class there is an empty implementation of this method.
protected void qualifyRequest(WorkspaceInfo workspace, LayerInfo layer, Service service, Request request)
That method should be called before the kvp parsers execute, and you should have access to the kvp map through the Request object.
Fine. I’ll take a look at that.
Thanks
Mauro
Hi Mauro, made some comments on the commit.
···
On Sun, Mar 24, 2013 at 2:52 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
Hi,
I finally found some time to craft a patch for this: https://github.com/mbarto/geoserver/commit/bd17a64ddac77b9f74c9f74b92ad9fefb3977938
If someone has some and could kindly do a review…
Thanks
Mauro Bartolomeoli
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/3/15 Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com>
2013/3/15 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I see. Well one potential fix would be to have the WFSWorkspaceQualifier hack the kvp map before it is parsed by the kvp readers.
Actually if you look at the class there is an empty implementation of this method.
protected void qualifyRequest(WorkspaceInfo workspace, LayerInfo layer, Service service, Request request)
That method should be called before the kvp parsers execute, and you should have access to the kvp map through the Request object.
Fine. I’ll take a look at that.
Thanks
Mauro
Hi,
I managed to fix the glitches you found and tried to run cite-tests for wfs 1.0 and 1.1. The 1.1 passed with no errors, the 1.0 had some failure (but the same tests were failing before applying the patch), so I’m confident the patch should not do any harm to cite tests.
If there are no objections I will make a pull request for this in a couple of days.
Thanks.
Mauro Bartolomeoli
···
2013/3/27 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro, made some comments on the commit.
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Sun, Mar 24, 2013 at 2:52 AM, Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com> wrote:
Hi,
I finally found some time to craft a patch for this: https://github.com/mbarto/geoserver/commit/bd17a64ddac77b9f74c9f74b92ad9fefb3977938
If someone has some and could kindly do a review…
Thanks
Mauro Bartolomeoli
–
Dott. Mauro Bartolomeoli
@mauro_bart
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
2013/3/15 Mauro Bartolomeoli <mauro.bartolomeoli@anonymised.com>
2013/3/15 Justin Deoliveira <jdeolive@anonymised.com>
Hi Mauro,
I see. Well one potential fix would be to have the WFSWorkspaceQualifier hack the kvp map before it is parsed by the kvp readers.
Actually if you look at the class there is an empty implementation of this method.
protected void qualifyRequest(WorkspaceInfo workspace, LayerInfo layer, Service service, Request request)
That method should be called before the kvp parsers execute, and you should have access to the kvp map through the Request object.
Fine. I’ll take a look at that.
Thanks
Mauro