[Geoserver-devel] Blacklisting extensions

Hi,
in GeoServer nowadays we have a number of extension points: output formats, part of the security subsystem, GUI pages and so on.

The system is purely additive, with priorities: one can add new
items, and in cases in which only the first extension out of a list
is picked, use the ExtensionPriority to make sure an extension gets
the upper hand over another one.

However, there is no way to remove an extension without removing
the jar in which it's stored. This is quite a bit limiting, consider
for example the output formats, it would be nice to have in the
GUI a configuration panel listing the available ones and allowing
the admin to decide which one to keep active, and which ones to remove.

Also, in general, one might want to remove a wicket page without
removing the whole module, for example, one might want to just remove
the demo requests page without giving up the preview one.

Given all extensions are grabbed using the
GeoServerExtensions.extensions(class)
method, I would propose a pluggable filtering mechanism allowing
for extension filtering (of course the extension filters would
not be black-listable to avoid a recursive situation).

The interface could look like:

ExtensionFilter {
   boolean isBlacklisted(Object extension);
}

if we just want to allow removal,
or it could look like:

ExtensionFilter {
   Object filter(Object extension)
}

if we want to allow both removal and, for any reason, wrapping
(return null if you want to remove).

GeoServerExtensions would lookup in the spring context the
ExtensionFilter objects and use them to filter out what is
being returned by GeoServerExtensions.extensions(class).

Thoughts?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

+1. Good idea.

I think I prefer the first version of the interface as its simpler. But i am not against the second version if we think we should go with the extra flexibility.

However, in the first version I think isBlacklisted() is a misnomer as it implies some how the extension is misbehaved which probably won't be the case i would think. I think just "boolean filter()" is a better name.

-Justin

Andrea Aime wrote:

Hi,
in GeoServer nowadays we have a number of extension points: output formats, part of the security subsystem, GUI pages and so on.

The system is purely additive, with priorities: one can add new
items, and in cases in which only the first extension out of a list
is picked, use the ExtensionPriority to make sure an extension gets
the upper hand over another one.

However, there is no way to remove an extension without removing
the jar in which it's stored. This is quite a bit limiting, consider
for example the output formats, it would be nice to have in the
GUI a configuration panel listing the available ones and allowing
the admin to decide which one to keep active, and which ones to remove.

Also, in general, one might want to remove a wicket page without
removing the whole module, for example, one might want to just remove
the demo requests page without giving up the preview one.

Given all extensions are grabbed using the
GeoServerExtensions.extensions(class)
method, I would propose a pluggable filtering mechanism allowing
for extension filtering (of course the extension filters would
not be black-listable to avoid a recursive situation).

The interface could look like:

ExtensionFilter {
   boolean isBlacklisted(Object extension);
}

if we just want to allow removal,
or it could look like:

ExtensionFilter {
   Object filter(Object extension)
}

if we want to allow both removal and, for any reason, wrapping
(return null if you want to remove).

GeoServerExtensions would lookup in the spring context the
ExtensionFilter objects and use them to filter out what is
being returned by GeoServerExtensions.extensions(class).

Thoughts?

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

+1. Good idea.

I think I prefer the first version of the interface as its simpler. But i am not against the second version if we think we should go with the extra flexibility.

However, in the first version I think isBlacklisted() is a misnomer as it implies some how the extension is misbehaved which probably won't be the case i would think. I think just "boolean filter()" is a better name.

Hmmm... if(filter(extension))... how do you read that? Inclusive or
exclusive? Filtering in or out?

Maybe "includes(extension))" or "isIncluded(...)"... as usual I'm weak
at naming stuff but something that should be used as a predicate
should sound like a question imho.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

+1. Good idea.

I think I prefer the first version of the interface as its simpler. But i am not against the second version if we think we should go with the extra flexibility.

However, in the first version I think isBlacklisted() is a misnomer as it implies some how the extension is misbehaved which probably won't be the case i would think. I think just "boolean filter()" is a better name.

Hmmm... if(filter(extension))... how do you read that? Inclusive or
exclusive? Filtering in or out?

I would read it as inclusive but yeah i can see how it is ambiguous. I like either of includes() or isIncluded().

Maybe "includes(extension))" or "isIncluded(...)"... as usual I'm weak
at naming stuff but something that should be used as a predicate
should sound like a question imho.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.