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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Kevin Smith
Junior Software Engineer | Boundless
[email protected]
+1-778-785-7459
@boundlessgeo <https://twitter.com/boundlessgeo>
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
