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.bartolome...@geo-solutions.it> wrote:
>
>
>
> 2013/3/5 Justin Deoliveira <jdeol...@opengeo.org>
>
>> 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
>
> --
> ==
> 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
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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_mar
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
