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.bartolome...@geo-solutions.it> wrote:
> Hi everybody.
>
> Today I encountered a strange behaviour in geoserver wfs, when used with
> workspace prefix in the request (/geoserver/<workspace>/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
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
