From: Martin Desruisseaux <martin.desruisseaux@no...> - 2005-03-21 11:22:25
Constraint to keep in mind: Some factories are costly to setup.
Plugin/epsg load a 1.5 Mb file; DatumAliases load a file too; EPSG
factory etablish a JDBC connection to a database. We don't want to setup
those factories everytime a 'getFooFactory()' method is invoked.
org.geotools.factory.FactoryFinder creates a new instance every time
findFactory(...) is invoked. javax.imageio.spi.ServiceRegistry
instantiates factories once for ever (which partially solve the
above-cited constraint), in addition to other advantages (ordering,
notification on registration/deregistration, standard in J2SE 1.4+,
etc.). This is why I suggest a ServiceRegistry based solution.
Jody's Hack.java file is a first step toward a map of hints in the
spirit of FactoryFinder. I wish to adapt it to the ServiceRegistry
Basic algorithm in Hack.java was:
1) If the users provides hints, creates a new factory accordingly.
2) Otherwise, fallback on the default factory.
The "If the users provides hints" condition needs to be elaborated. For
example plugin/epsg doesn't care about the "GEOMETRY_FACTORY" hint. We
should not setup a new plugin/epsg instance that loads again 1.5 Mb of
data because the map (probably created in some high level place, e.g. at
application startup) contains a hint not targeted toward plugin/epsg.
In FactoryRegistry (an extension of ServiceRegistry), when the user asks
for a factory, we first search into all registered factories for an
instance that already meets the user's requirement. The check is
performed by comparing user's hints against factory's hints as returned
Only if no factory meeting user's requirement is found, FactoryCreator
(a FactoryRegistry subclass) will creates a new instance. In current
implementation, new instances are not cached or registered. They are
temporary objects created in the same way than Hack.java did. Only
implementation registered in META-INF/services are stored in
It still work in progress. Comments welcome.