I had some thoughts about how to extend our extension lookup mechanism slightly and wanted to start some conversation on the subject.
My use case is that I want to contribute implementations to the various geoserver extension points, output formats, transaction hooks, etc… from python (or any scripting environment for that matter). And I don’t really want to register beans in the spring context and restart the server when i add a new one.
So, the idea. The idea is to add a new interface called ExtensionProvider that would look something like this:
interface ExtensionProvider {
List ExtensionProvider(Class extensionPoint);
}
Implementations of which would be registered in the spring context as per usual. Then modify the GeoServerExtensions class to use any instances of this interface when being asked to do an extension point lookup.
Thoughts? Comments?
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I had some thoughts about how to extend our extension lookup mechanism slightly and wanted to start some conversation on the subject.
My use case is that I want to contribute implementations to the various geoserver extension points, output formats, transaction hooks, etc... from python (or any scripting environment for that matter). And I don't really want to register beans in the spring context and restart the server when i add a new one.
So, the idea. The idea is to add a new interface called ExtensionProvider that would look something like this:
Implementations of which would be registered in the spring context as per usual. Then modify the GeoServerExtensions class to use any instances of this interface when being asked to do an extension point lookup.
Thoughts? Comments?
Sounds like a good idea, there is a catch though.
The Spring lookups are heavy so we cache the results, what are we
going to do with this new extension source?
Is it supposed to be fast enough that we can query it every time?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well my thought is that the lookup for the ExtensionProviders themselves will be cached so as long as the ExtensionProvider implementations themselves are fast then it should be fast enough to query them each time. However is one is slow then the entire lookup will be slow. And in the case i am working on it will involve going to disk to check for new script files and parsing scripts… However the case of contributing extensions via scripts a cache would be problematic as the available extensions is likely to change.
Perhaps could add another cache for specific to ExtensionProviders themselves. And perhaps add a flag to the ExtensionProvider interface itself:
to allow the implementation the choice of whether it should be cached or not. Or perhaps be a little smarter and allow the extension to report when it needs to be reprocess:
I had some thoughts about how to extend our extension lookup mechanism slightly and wanted to start some conversation on the subject.
My use case is that I want to contribute implementations to the various geoserver extension points, output formats, transaction hooks, etc… from python (or any scripting environment for that matter). And I don’t really want to register beans in the spring context and restart the server when i add a new one.
So, the idea. The idea is to add a new interface called ExtensionProvider that would look something like this:
interface ExtensionProvider {
List ExtensionProvider(Class extensionPoint);
}
Implementations of which would be registered in the spring context as per usual. Then modify the GeoServerExtensions class to use any instances of this interface when being asked to do an extension point lookup.
Thoughts? Comments?
Sounds like a good idea, there is a catch though.
The Spring lookups are heavy so we cache the results, what are we
going to do with this new extension source?
Is it supposed to be fast enough that we can query it every time?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Well my thought is that the lookup for the ExtensionProviders themselves will be cached so as long as the ExtensionProvider implementations themselves are fast then it should be fast enough to query them each time. However is one is slow then the entire lookup will be slow. And in the case i am working on it will involve going to disk to check for new script files and parsing scripts... However the case of contributing extensions via scripts a cache would be problematic as the available extensions is likely to change.
Perhaps could add another cache for specific to ExtensionProviders themselves. And perhaps add a flag to the ExtensionProvider interface itself:
to allow the implementation the choice of whether it should be cached or not. Or perhaps be a little smarter and allow the extension to report when it needs to be reprocess:
Well, in the end a FS based one is not cacheable. Having a way to
cache the result until modified could be intersting to factor out
code, but that can be also provided through a wrapper (or base) class
which factors out this caching aspect.
In the end I don't think it'll buy us much... I mean, we should
just tell the implementors of those providers that:
- lookups for a class other than the one they produce should
be damn fast (e.g., check that in the first row of your method,
or have the provider declare what kind of extension it generates)
- lookups for the specific extension point should be as fast as
possible, knowing that a slow one will drag down the entire
system with itself.
Eclipse has this issue and I think it ends up banning extensions
that take too much time to process a certain extension point.
Could be a way, but it can also be added later: for the moment let's
just try document it and be careful?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well my thought is that the lookup for the ExtensionProviders themselves will be cached so as long as the ExtensionProvider implementations themselves are fast then it should be fast enough to query them each time. However is one is slow then the entire lookup will be slow. And in the case i am working on it will involve going to disk to check for new script files and parsing scripts… However the case of contributing extensions via scripts a cache would be problematic as the available extensions is likely to change.
Perhaps could add another cache for specific to ExtensionProviders themselves. And perhaps add a flag to the ExtensionProvider interface itself:
to allow the implementation the choice of whether it should be cached or not. Or perhaps be a little smarter and allow the extension to report when it needs to be reprocess:
Well, in the end a FS based one is not cacheable. Having a way to
cache the result until modified could be intersting to factor out
code, but that can be also provided through a wrapper (or base) class
which factors out this caching aspect.
In the end I don’t think it’ll buy us much… I mean, we should
just tell the implementors of those providers that:
lookups for a class other than the one they produce should
be damn fast (e.g., check that in the first row of your method,
or have the provider declare what kind of extension it generates)
lookups for the specific extension point should be as fast as
possible, knowing that a slow one will drag down the entire
system with itself.
Eclipse has this issue and I think it ends up banning extensions
that take too much time to process a certain extension point.
Could be a way, but it can also be added later: for the moment let’s
just try document it and be careful?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Hey Justin - this is similar to the lookup interface from netbeans
(http://wiki.netbeans.org/AboutLookup). I would really like something
like this at the GeoTools level; especially to allow spring to
configure some of the geotools relationships if it wants.
Do you have any interest at doing this at the GeoTools level?
Jody
On Wed, Aug 25, 2010 at 12:20 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:
Hi all,
I had some thoughts about how to extend our extension lookup mechanism
slightly and wanted to start some conversation on the subject.
My use case is that I want to contribute implementations to the various
geoserver extension points, output formats, transaction hooks, etc... from
python (or any scripting environment for that matter). And I don't really
want to register beans in the spring context and restart the server when i
add a new one.
So, the idea. The idea is to add a new interface called ExtensionProvider
that would look something like this:
interface ExtensionProvider<T> {
List<T> ExtensionProvider(Class<T> extensionPoint);
}
Implementations of which would be registered in the spring context as per
usual. Then modify the GeoServerExtensions class to use any instances of
this interface when being asked to do an extension point lookup.
Thoughts? Comments?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Interesting. Yeah i think something could be done fairly easily at the geotools level. All it would take is a similar interface and a custom FactoryIteratorProvider to load them… I will try to whip up a patch.
Hey Justin - this is similar to the lookup interface from netbeans
(http://wiki.netbeans.org/AboutLookup). I would really like something
like this at the GeoTools level; especially to allow spring to
configure some of the geotools relationships if it wants.
Do you have any interest at doing this at the GeoTools level?
Hi all,
I had some thoughts about how to extend our extension lookup mechanism
slightly and wanted to start some conversation on the subject.
My use case is that I want to contribute implementations to the various
geoserver extension points, output formats, transaction hooks, etc… from
python (or any scripting environment for that matter). And I don’t really
want to register beans in the spring context and restart the server when i
add a new one.
So, the idea. The idea is to add a new interface called ExtensionProvider
that would look something like this:
interface ExtensionProvider {
List ExtensionProvider(Class extensionPoint);
}
Implementations of which would be registered in the spring context as per
usual. Then modify the GeoServerExtensions class to use any instances of
this interface when being asked to do an extension point lookup.
Thoughts? Comments?
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Sell apps to millions through the Intel(R) Atom™ Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
I would like to use an approach similar to netbeans lookup (ie one
level up from an iterator). Simply to help with unloading; loading ..
and chances are we could handle caching with a wrapper.
Jody
On Thu, Aug 26, 2010 at 12:54 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:
Interesting. Yeah i think something could be done fairly easily at the
geotools level. All it would take is a similar interface and a custom
FactoryIteratorProvider to load them... I will try to whip up a patch.
On Tue, Aug 24, 2010 at 10:11 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
Hey Justin - this is similar to the lookup interface from netbeans
(http://wiki.netbeans.org/AboutLookup). I would really like something
like this at the GeoTools level; especially to allow spring to
configure some of the geotools relationships if it wants.
Do you have any interest at doing this at the GeoTools level?
Jody
On Wed, Aug 25, 2010 at 12:20 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:
> Hi all,
> I had some thoughts about how to extend our extension lookup mechanism
> slightly and wanted to start some conversation on the subject.
> My use case is that I want to contribute implementations to the various
> geoserver extension points, output formats, transaction hooks, etc...
> from
> python (or any scripting environment for that matter). And I don't
> really
> want to register beans in the spring context and restart the server when
> i
> add a new one.
> So, the idea. The idea is to add a new interface called
> ExtensionProvider
> that would look something like this:
> interface ExtensionProvider<T> {
>
> List<T> ExtensionProvider(Class<T> extensionPoint);
> }
> Implementations of which would be registered in the spring context as
> per
> usual. Then modify the GeoServerExtensions class to use any instances of
> this interface when being asked to do an extension point lookup.
> Thoughts? Comments?
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue
> and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.