Very cool idea. That could lead to some very interesting extensions
indeed. Since we already have a CatalogListener interface I would
probably recommend a different name. Something like
"ResourceAccessListener" maybe makes more sense?
Andrea Aime wrote:
> Hi,
> I'm looking into making the GeoServer catalog provide
> events when layers are accessed. Something useful, for example,
> for any kind of request accounting.
>
> The idea I have in mind at the moment is pluggable listeners,
> registered in the Spring context at application startup,
> that would be notified each time:
> - a feature type is accessed, with information about the
> query/filter used
> - a feature type is modified, with information about the
> area modified
> - a coverage is accessed, with information about the
> bbox read
>
> In general the listening interface could be something like:
>
> CatalogListener {
> void resourceRead(ResourceInfo resource, Filter filter);
> void resourceModified(ResourceInfo resource, Filter filter);
> }
>
> where Filter is an OGC filter stating what part of the data
> is being accessed/modified. For coverages I guess it would
> just be a bbox filter built on the fly.
>
> This would form the basis for an accounting that works
> not matter what service is used to access the data
> (WMS, WFS, WCS, WPS, custom REST extensions of the day).
>
> Feature type wise I think that would require adding
> some event firing code inside GeoServerFeatureSource
> and GeoServerFeatureStore. For read wise notifications
> we just need to add event firing methods to GeoServerFeatureSource
> code, for write wise stuff I guess we could rely on
> the existing FeatureListener stuff (or we could use
> the WFS-T transaction callbacks, but what if someone
> adds a custom restlet that does change data?)
>
> Coverage wise I think we could create a coverage reader wrapper
> that does the same. Thinking about it, I believe we need a
> wrapper anyways if we want to allow forcing in a SRS
> into coverages like we do for vectors (something would
> be very handy instead of having to fix the original
> data every time by creating a .prj file).
>
> Overhead wise we should be good considering that those
> listeners are registered in the spring context, so we
> could grab the list of them just once and keep it around,
> and avoid firing the events at all if there is no
> registered listener.
>
> Opinions?
>
> Cheers
> Andrea
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
