> That would be great to have some feedback from GeoTools core > developers (Jody?) about my previous mail, especially with regard to > the hack I had to do in order to refresh the registry (since it caches > the instances). > > I used a static method found in the referencing part, that's probably > why it only covers that. The hack was expected (hence I did not comment). I have been working on splitting out service discovery from factory registry (as they are two different issues, the registry is not available on andriod, and it does not provide a way for you to "hack"). My idea was that you would issue events - and the registery would update its cache of factory instances??
>From the javadocs of my uncommitted work (you can see the code example showing >the separation). The Lookup provides a listener api allowing the registery to >notice when an implementation is no longer available (due to a bundle being >unloaded I presume). The Lookup only deals with providing an implementation >(ie a no argument constructor or reference by some kind of string id) and is >general purpose. The Register is GeoTools factory specific; willing to deal with the Hints system (and have several instances of a Factory configured differently). org.geotools.util.lookup.Lookup Lookup provides a common target for GeoTools FactoryFinder when working within different plugin systems. The concept is split into two: All client code should be using FactoryFinder to look up an implementation of a Factory for the task at hand. Factories are cached for reuse, however clients can use Hints when asking for a factory and may get back an instance configured with those hints in mind. Example: FilterFactory ff = CommonFactoryFinder.getFilterFactory(null); We force users to supply hints (even if null) so that they are aware that configuration is possible. All FactoryFinders should consult the GeoTools configuration class; and ask for a Lookup instance used to retrieve a Service. Lookup lookup = GeoTools.lookup(FilterService.class); FactoryRegisery registery = new FactoryRegistery(FilterFactory.class, lookup); Formally the class FactoryRegistery was used for this purpose; it is however not available on Andriod providing motivation for this Lookup class. As indicated by the examples above; most of the time the Service we are interested in is a factory. We have provided a Registery class that can be used to take on the responsibility of managing Factory configuration and Hints.Please note that the above example shows a FactoryFinder meeting its responsibility in two steps. Lookup is used to determine to find a Service. Each jar can contribute one or more Service instances. These Service instances have no configuration and are only once (The Lookup will hold on to an instnace and return it again if asked). A no argument consturctor is used to create each service instance. Registery is used to specifically manage the relationship between Factory and Hints. It will basically store Factory instances using Hints. A Factory(Hints) constructor is used; with the Factory having a chance to return getSupportedHints() in order to communicate the subset of hints it used. The factories are basically stored as a Map with the key being the supported hints used for configuration.,factory>Note some event facilities are provided in order to allow dynamic systems to register and unregister additional services as they are made available. Note: This is provided as an abstract class as we expect implementators to wrap the plugin mechanism used (rather than extend). This code is inspired by NetBeans Lookup class (which is inspired by the JINI solution to this issue). As we do not expect client code to use this directly we focus on providing a Set of resutls for use by FactoryFinders.
CategoryListener.java
Description: Binary data
JDK5Lookup.java
Description: Binary data
JDK6Lookup.java
Description: Binary data
ListLookup.java
Description: Binary data
Lookup.java
Description: Binary data
ServiceEntryImpl.java
Description: Binary data
SingleLookup.java
Description: Binary data
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
