[Geoserver-devel] Having integrated GWC proxy all "unknown" WMS requests to the internal GeoServer

Hi,
I’m looking into having GWC own WMS reply to GetLegendGraphics, which is something
the stand-alone version can do, but the embedded one can not.

Now, stand alone GWC has the following setup:

  • GetFeatureInfo gets a special treatment, any GWC layer implementation is supposed to provide
    support for it via a dedicated method (which might be throwing an exception, but an implementation
    of the method has to be there)
  • For all other WMS requests, there is a special arrangement in the WMS service that check if the
    layer is a WMSLayer, and in that case, cascades the request

Now, GeoServer integrated layers are GeoServerTileLayer instances, which are not subclasses
of WMSLayer, so neither arrangement works.

One approach could be to ask all GWC layers to support a custom getLegendGraphics method,
mimicking GetFeatureInfo, but seems a bit heavy handed, and what we do when someone
wants GetStyles support too? Or DescribeLayer?

Another approach could be to roll out a ProxyLayer interface, with a method dedicated to proxying:

ProxyResponse proxy(HttpServletRequest request);

where ProxyResponse would provide a status, a content type, a list of headers and their values, and
an input stream for the response to be sent back.
Then WMSLayer in GWC could implement that, and GeoServerTileLayer implement it as well,
keeping the proxying generic.

Yet another approach would be to tap into the GWC integration at the GwcServiceProxy.dispatch
level, see if the response is one of those that GWC can handle natively, if not, check if the
layer is known to GeoServer, and redirect the request to the internal WMS instead.

Opinions? What if I wanted to backport to the stable series, 2.4.x, would that change your opinion
on which approach is best?

Personally I like the second one (ProxyLayer interface) better, it allows for future extension and
custom layers to try and do some cascading, and the interface is new, so it would not break
existing implementations.

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

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


ProxyLayer seems like the best solution to me for being clean and extensible for new functionality. Backportability doesn’t seem like it would be a problem but it feels a bit off in that regard, even if it is just an addition. That said, there’s one backported fix on GWC 1.5 already so it needs a 1.5.1 anyway.

···

On 4 November 2013 09:36, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’m looking into having GWC own WMS reply to GetLegendGraphics, which is something
the stand-alone version can do, but the embedded one can not.

Now, stand alone GWC has the following setup:

  • GetFeatureInfo gets a special treatment, any GWC layer implementation is supposed to provide
    support for it via a dedicated method (which might be throwing an exception, but an implementation
    of the method has to be there)
  • For all other WMS requests, there is a special arrangement in the WMS service that check if the
    layer is a WMSLayer, and in that case, cascades the request

Now, GeoServer integrated layers are GeoServerTileLayer instances, which are not subclasses
of WMSLayer, so neither arrangement works.

One approach could be to ask all GWC layers to support a custom getLegendGraphics method,
mimicking GetFeatureInfo, but seems a bit heavy handed, and what we do when someone
wants GetStyles support too? Or DescribeLayer?

Another approach could be to roll out a ProxyLayer interface, with a method dedicated to proxying:

ProxyResponse proxy(HttpServletRequest request);

where ProxyResponse would provide a status, a content type, a list of headers and their values, and
an input stream for the response to be sent back.
Then WMSLayer in GWC could implement that, and GeoServerTileLayer implement it as well,
keeping the proxying generic.

Yet another approach would be to tap into the GWC integration at the GwcServiceProxy.dispatch
level, see if the response is one of those that GWC can handle natively, if not, check if the
layer is known to GeoServer, and redirect the request to the internal WMS instead.

Opinions? What if I wanted to backport to the stable series, 2.4.x, would that change your opinion
on which approach is best?

Personally I like the second one (ProxyLayer interface) better, it allows for future extension and
custom layers to try and do some cascading, and the interface is new, so it would not break
existing implementations.

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

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



Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Kevin Smith

Junior Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

On Tue, Nov 5, 2013 at 12:52 AM, Kevin Smith <ksmith@anonymised.com>wrote:

ProxyLayer seems like the best solution to me for being clean and
extensible for new functionality. Backportability doesn't seem like it
would be a problem but it feels a bit off in that regard, even if it is
just an addition. That said, there's one backported fix on GWC 1.5 already
so it needs a 1.5.1 anyway.

Roger that, thanks for the feedback.
Not sure if/when the change will be made (at the moment I'm just discussing
it), but always
better to have a clear idea of what would be the best approach before
getting down to
coding stuff :slight_smile:

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

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

-------------------------------------------------------