Jody Garnett a écrit : > I wrote some initial instructions on the developers guide, I see Jesse > has updated them a bit - but the level > of detail required for planning is missing. I am not sure exactly what > is going on and how much is global?
You means this page? http://docs.codehaus.org/display/GEOT/8.3+Plugins+and+FactoryFinder I will look again if I can suggest some edition... > There are two implementations of FactoryRegistry: > - FactoryCreator - A FactoryRegistry factory registry capable to creates > factories if no appropriate instance was found in the registry. > - Registry - Defines static methods used to access GeometryFactory, > CoordinateSequenceFactory or PrecisionModel factories. The later one is private, for org.geotools.geometry.jts.FactoryFinder internal usage only. In most case, there is no need to create FactoryFinder subclasses other than the one already provided in org.geotools.factory. An exception to this rule is when we want to work with non-geotools factories (JTS factories in this case), in which case we need to override some hooks. > So where does the collection of classes come from? This is the list of interfaces implemented by the module. For example if a FactoryFinder provides a 'createGeometryFactory' method, then the list must contains a 'GeometryFactory.class' entry in order to tell FactoryRegistry that it must search for implementations listed in "META-INF/org...GeometryFactory" file. > And here is our first indication that this thing is intended to be used > as a singleton (in the only used instance IIORegistry): >> /** >> * Returns the default <code>IIORegistry</code> instance used by >> * the Image I/O API. This instance should be used for all >> * registry functions. >> */ Yes, a singleton for Image IO encoder/decoders. This doesn't means a singleton for every interfaces in a JVM. > - ServiceRegistry is designed to be used used as a singleton - one per > thread group ... and per set of services provided (loosely speaking, we could said "per module"). Image I/O provides a set of services. The referencing module provides an other set of services, etc. We do not expect Image I/O and referencing framework to share the same ServiceRegistry. So I will try to clarify this FactoryRegistry singleton issue. I should wrote that before, but it needed clarification in my own head before I can write that... * We need a singleton at least for a given service. For example we absolutly need a FactoryRegistry singleton for all implementations of the CRSFactory interface, and a singleton for all implementations of the MathTransformFactory interface. * We can use the same FactoryRegistry singleton for both CRSFactory and MathTransformFactory, but we don't have too. Sharing the same FactoryRegistry singleton or not is a somewhat conceptual choice: I do it for closely related services. * We considered a System-wide FactoryRegistry singleton because the add/removeFactoryIteratorProvider(...) methods were defined there, and we wanted them to have a system-wide effect. But instead of making FactoryRegistry a singleton (for the reason explained later), I moved the add/removeFactoryIteratorProvider(...) methods as static ones in the new system-wide Factories class. * As far as I know, there is no remaining method in FactoryRegistry that we want system-wide at this time, except maybe 'scanForPlugins'. If such methods appears later, we can put them in the new Factories system-wide class too. * There is reasons for using one FactoryRegistry instance per module instead of a system-wide FactoryRegistry: - The list given to the constructor should contains only the list of services implemented by a specific module. If FactoryRegistry was system-wide, we would have to list all Geotools services in the singleton, including services in JAR files that the user don't want on the classpath. - More fine-grain synchronization, instead of synchronization against a system-wide lock. - Safer (less risk of interference between unrelated registries). Some questions that I have are: * We wanted a FactoryRegistry singleton in order to have a central place to configure stuff like FactoryIteratorProviders. If this central place is org.geotools.factory.Factories, do I missed an other reason to make FactoryRegistry singleton? * Is there other global configuration to provide appart 'add/removeFactoryIteratorProvider()' and maybe 'scanForPlugins()'? * Does the proposed org.geotools.factory.Factories class (currently on trunk) can meet the needs... * Does it seems too complicated for what we try to do? Or a wrong design? Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
