Works for me. Would the ProcessFilter also be plugged-in at the SPI level?
On Wed, Nov 9, 2011 at 7:32 AM, Andrea Aime <[email protected]>wrote:
> Hi,
> in GeoServer land I'm currently tasked with this requirement to make the
> WPS processes available to the end user, either statically, because the
> admin simply does not want something, or dynamically, based on the
> current user rights.
>
> Filtering SPI extensions is kind of a general problem, but we normally
> don't
> see it much because often the SPI implementations are rather coarse
> and we have one per jar: think stores, coverage readers.
> For those one often simply does not add the jars that are not desired.
>
> However there are others that are much more fine grained and a single
> jar carries many: processes are an example, but filter functions or
> converters could be considered as well.
>
> Now, why can't I just filter at the application level?
> If it was just for WPS I could indeed just have the WPS use a service
> to locate the processes and be done with it.
>
> However processes are now become part of filters functions and
> rending world via rendering transformations, and there the lookup
> cannot simply use some GeoServer specific mechanism unless
> I open an extension point to do so.
> In particular I would like to disallow heavy processes to be used
> as rendering transformations or filter functions, at least give
> the administrator some control on what gets used where.
>
> A solution could be to have a pluggable process filter that can filter
> and wrap the factories:
>
> interface ProcessFilter {
> ProcessFactory filter(ProcessFactory factory);
> }
>
> If it returns null the factory is banned, otherwise it is free to wrap
> the factory so that certain processes in the factory are disallowed,
> or maybe wrapped so that they throw exception under particular
> conditions, such as too large inputs.
>
> Opinions?
>
> Cheers
> Andrea
>
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel