The ticket outlines the issue in more depth but the crux of the problem is that DescribeLayer returns URLs with ‘WfsDispatcher’ on the end, something like: http://localhost:8080/geoserver/tiger/poi/wfs/WfsDispatcher?
These URLs are not usable as an exception occurs noting that the service can’t be found or operation doesn’t exist. The issue occurs with both {workspace} and {workspace}/{layer} virtual services.
The problem occurs here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L369
The code only looks for a single slash…
I attempted a fix in the Dispatcher and it will work for URLs of the format {workspace}/{layer} but this fails with the {workspace} only approach as the context is computed as {workspace}/wfs and the path is WfsDispatcher. This algorithm is ambiguous unless it ‘knows’ about ‘WfsDispatcher’.
It seems like potential solutions are:
- remove WfsDispatcher from the DescribeLayer response (the code even notes this: https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/describelayer/DescribeLayerTransformer.java#L153 ). The String WfsDispatcher only appears a few times throughout the codebase.
- and/or (if desired for backward compatibility) make the Dispatcher knowledgeable about this specific type of URL (ending w/ WfsDispatcher) and ignore the last path component
Clear as mud?
Thoughts?
–
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
On Fri, Oct 11, 2013 at 6:11 PM, Ian Schneider
<ischneider@anonymised.com>wrote:
The ticket outlines the issue in more depth but the crux of the problem is
that DescribeLayer returns URLs with 'WfsDispatcher' on the end, something
like: http://localhost:8080/geoserver/tiger/poi/wfs/WfsDispatcher?
These URLs are not usable as an exception occurs noting that the service
can't be found or operation doesn't exist. The issue occurs with both
{workspace} and {workspace}/{layer} virtual services.
The problem occurs here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L369
The code only looks for a single slash...
I attempted a fix in the Dispatcher and it will work for URLs of the
format {workspace}/{layer} but this fails with the {workspace} only
approach as the `context` is computed as {workspace}/wfs and the `path` is
WfsDispatcher. This algorithm is ambiguous unless it 'knows' about
'WfsDispatcher'.
It seems like potential solutions are:
1) remove WfsDispatcher from the DescribeLayer response (the code even
notes this:
https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/describelayer/DescribeLayerTransformer.java#L153). The String WfsDispatcher only appears a few times throughout the
codebase.
2) and/or (if desired for backward compatibility) make the Dispatcher
knowledgeable about this specific type of URL (ending w/ WfsDispatcher) and
ignore the last path component
I did not put much thinking nor checked the code much, but that
WfsDispatcher thing is a long gone one (like,
stopped being used before I joined the dev team 6-7 years ago), and we have
just some tiny backwards
compatibility support.
I'd say, let's have it die and make describe layer return some "modern"
DescribeFeatureType link instead?
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
The complete death of the WfsDispatcher here: https://github.com/geoserver/geoserver/pull/356
Do you reckon it would be okay to cherry-pick to 2.3.x, too?
···
On Fri, Oct 11, 2013 at 11:34 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Oct 11, 2013 at 6:11 PM, Ian Schneider <ischneider@anonymised.com> wrote:
–
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
The ticket outlines the issue in more depth but the crux of the problem is that DescribeLayer returns URLs with ‘WfsDispatcher’ on the end, something like: http://localhost:8080/geoserver/tiger/poi/wfs/WfsDispatcher?
These URLs are not usable as an exception occurs noting that the service can’t be found or operation doesn’t exist. The issue occurs with both {workspace} and {workspace}/{layer} virtual services.
The problem occurs here:
https://github.com/geoserver/geoserver/blob/master/src/ows/src/main/java/org/geoserver/ows/Dispatcher.java#L369
The code only looks for a single slash…
I attempted a fix in the Dispatcher and it will work for URLs of the format {workspace}/{layer} but this fails with the {workspace} only approach as the context is computed as {workspace}/wfs and the path is WfsDispatcher. This algorithm is ambiguous unless it ‘knows’ about ‘WfsDispatcher’.
It seems like potential solutions are:
- remove WfsDispatcher from the DescribeLayer response (the code even notes this: https://github.com/geoserver/geoserver/blob/master/src/wms/src/main/java/org/geoserver/wms/describelayer/DescribeLayerTransformer.java#L153 ). The String WfsDispatcher only appears a few times throughout the codebase.
- and/or (if desired for backward compatibility) make the Dispatcher knowledgeable about this specific type of URL (ending w/ WfsDispatcher) and ignore the last path component
I did not put much thinking nor checked the code much, but that WfsDispatcher thing is a long gone one (like,
stopped being used before I joined the dev team 6-7 years ago), and we have just some tiny backwards
compatibility support.
I’d say, let’s have it die and make describe layer return some “modern” DescribeFeatureType link instead?
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On Fri, Oct 11, 2013 at 11:46 PM, Ian Schneider <ischneider@anonymised.com
wrote:
The complete death of the WfsDispatcher here:
https://github.com/geoserver/geoserver/pull/356
Hi Ian,
the patch looks good to me, those comments about supporting WfsDispatcher
are as old as GeoServer 1.4.0,
so I believe it's high time to let that thing go.
I have a bit of hesitation about dropping support for WfsDispatcher on
2.4.x, since it's a stable series,
but that url has been deprecated for so long that I'm good merging on 2.4.x
as well.
Do you reckon it would be okay to cherry-pick to 2.3.x, too?
2.3.x won't does not have any more planned releases, so in a sense the
branch is dead, no objections
back porting this change there
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Sat, Oct 12, 2013 at 3:24 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Fri, Oct 11, 2013 at 11:46 PM, Ian Schneider <
ischneider@anonymised.com> wrote:
The complete death of the WfsDispatcher here:
https://github.com/geoserver/geoserver/pull/356
Hi Ian,
the patch looks good to me, those comments about supporting WfsDispatcher
are as old as GeoServer 1.4.0,
so I believe it's high time to let that thing go.
I have a bit of hesitation about dropping support for WfsDispatcher on
2.4.x, since it's a stable series,
but that url has been deprecated for so long that I'm good merging on
2.4.x as well.
Agreed, my thought is that the only cases that this url would be used is
cases like this where the client is simply following the url provided by
the DescribeLayer endpoint. I vote for merge as is and if it really does
cause a regression with clients needing the WfsDispatcher endpoint we can
add the special case in the dispatcher (or perhaps hack it in with a
callback) for the 2.4.x series.
Do you reckon it would be okay to cherry-pick to 2.3.x, too?
2.3.x won't does not have any more planned releases, so in a sense the
branch is dead, no objections
back porting this change there
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>
On Sat, Oct 12, 2013 at 11:16 AM, Justin Deoliveira <
jdeolive@anonymised.com> wrote:
On Sat, Oct 12, 2013 at 3:24 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:
On Fri, Oct 11, 2013 at 11:46 PM, Ian Schneider <
ischneider@anonymised.com> wrote:
The complete death of the WfsDispatcher here:
https://github.com/geoserver/geoserver/pull/356
Hi Ian,
the patch looks good to me, those comments about supporting WfsDispatcher
are as old as GeoServer 1.4.0,
so I believe it's high time to let that thing go.
I have a bit of hesitation about dropping support for WfsDispatcher on
2.4.x, since it's a stable series,
but that url has been deprecated for so long that I'm good merging on
2.4.x as well.
Agreed, my thought is that the only cases that this url would be used is
cases like this where the client is simply following the url provided by
the DescribeLayer endpoint. I vote for merge as is and if it really does
cause a regression with clients needing the WfsDispatcher endpoint we can
add the special case in the dispatcher (or perhaps hack it in with a
callback) for the 2.4.x series.
As Justin notes, the only place the URL even showed up was the
DescribeLayer endpoint. Both workspace and layer virtual URLs (of the
...wfs/WfsDispatcher type) had been broken for some time, so my guess is
not many folks were actually using this.
Do you reckon it would be okay to cherry-pick to 2.3.x, too?
2.3.x won't does not have any more planned releases, so in a sense the
branch is dead, no objections
back porting this change there
Cool, merged to 2.3.x, 2.4.x and master.
--
Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com