Martin Desruisseaux wrote: > 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... Thanks - one thing we can do is remove the GeoTools 2.1 instructions - and the classes they talk about. >> 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): > Yes, a singleton for Image IO encoder/decoders. This doesn't means a > singleton for every interfaces in a JVM. Agreed - it does mean we need a singleton for every factory used in GeoTools - as with the IIORegistry we can have one singleton handle the registry for for several factories - currently we have split up by module. The implementation looks good (in terms of breaking things up by thread group). >> - 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. I think you are onto something :-) Clarification on your Clarification by service you mean the "big ticket" items that we usually handle one module at a time? Providing and additional CRSAuthorityFactory, defining support for a new DataStore etc. How fine grain do you want/need to go? It could be that Factory captures the correct level of detail already - since many Factory interfaces construct all the needed content for their operation. But with GeometryFactory, PrimitiveFactory etc this idea breaks down (you need to look up too much content to be productive). > * 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. My concern is that singletons are not "in one spot" - so when I drop GeoTools into more interesting environments I am going to be up for a murderous debugging session. > * 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. If I view FactoryRegistry as the "glue code" for GeoTools there is a couple of things still missing: - look up of created instances using well known name (JNDI?) - How the mapping from parameters to instance is handled (ignoring factory) an instance may of been provided already by the application, or may only need to be created just once "EPSG:4326" -> CoordinateReferenceSystem - and so on ... > * 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. I think this is more because we are outgrowing FactoryRegistry then anything else. I do however understand that this is a technical limitation of FactoryRegistry. Here is an easy example - right now referencing.FactoryFinder has a FactoryRegistry that is used to track CRSAuthrotyFactories. I am moving into a environment (J2EE) where the DataSource must be provided - this requirement was not know when referencing.FactoryFinder was produced - it is only introduced by an implementation that referencing.FactoryFinder picks up on the classpath. But the requirement is still real; and must be met and managed. We will *never* know what new implementations require (we cannot have a fixed list in the way FactoryRegistery desires). If I treat this as "glue code" to bind GeoTools together FactoryRegistry is a bad choice based on this limitation. > - More fine-grain synchronization, instead of synchronization against a > system-wide lock. Not sure this one works - performance concerns can be solved (we could synchronize on the InRegistry since we are only using the map for look up by class). > - Safer (less risk of interference between unrelated registries). Interference is what I am after :-) Specifically with registries I have not yet met. > 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? A one stop shop for setting up the GeoTools library prior to use is the goal. You got it. The secondary reason is to isolate singleton use so we can *stop* having a singleton later in life - a library that is keeping a singleton is a pretty bad library. > * Is there other global configuration to provide appart > 'add/removeFactoryIteratorProvider()' and maybe 'scanForPlugins()'? Setting of JNDI initial context, logging settings, providing known implementations (to the application) of DataSource, CRSAuthorityFactory, GeometryFactory and so on). > * Does the proposed org.geotools.factory.Factories class (currently on > trunk) > can meet the needs... Not sure yet. > * Does it seems too complicated for what we try to do? Or a wrong design? It does offer one part of the solution (for application integration). It allows the application to advertise additional factories to GeoTools. The above list (logging, known instances) should be the rest of it. Well I suppose we may want graphics settings as well. Jody ------------------------------------------------------------------------- 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
