I'll add some documentation on the caching interceptors. Both in the
extension point and the interface. The resources are cached so that
things such as listeners only need to be added once and to reduce the
proliferation of newly created objects. For example if a new feature
store was returned each time then every plugin that is interested in
events would need to create a resource interceptor and every request
for a FeatureStore would result in both a new FeatureStore and a new
listener for every interested plugin. Since the Datastore's Listener
manager often keeps the listeners indefinately then we would very
quickly have 10s to 100s of listeners that can't be garbage collected
and possibly featurestores as well.
It has been made part of the resource interceptor extension point
because it is logically associated with them and so that extenders
can specify the caching strategy that applies to their application.
I can see cases where certain resources shouldn't be cached or where
the cache may need to be emptied on occasion.
Jesse
On 18-Oct-06, at 7:32 AM, Vitali Diatchkov wrote:
1)
By the way. The "interceptors" mechanism is nice, but seems not enough
thought out.
What are the caching interceptors? Resource? Whether they must be
called
once during resource creating and caching? Difference between pre/
post?
Missing docs is confusing, hope to clear the situation soon:)
Vitali.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
