Package org.geotools.factory

Utility classes which enable dynamic binding to factory implementations at runtime.

See:
          Description

Interface Summary
Factory Base interface for Geotools factories (i.e. service discovery).
OptionalFactory An optional factory that may not be available in all configurations.
 

Class Summary
AbstractFactory Skeletal implementation of factories.
BasicFactories Defines a common abstraction for getting the different factories.
FactoryCreator A factory registry capable to creates factories if no appropriate instance was found in the registry.
FactoryFinder Deprecated. The proposed replacement is FactoryRegistry, which is built on top of a J2SE class (ServiceRegistry).
FactoryRegistry A registry for factories, organized by categories (usualy by interface).
FactoryUsingVolatileDependencies Deprecated. This class should be a marker interface instead of an subclass.
Hints A set of hints providing control on factories to be used.
Hints.Key The type for keys used to control various aspects of the factory creation.
JNDI Provides initial context for Java Naming and Directory Interfaces (JNDI) in Geotools.
 

Exception Summary
FactoryNotFoundException Thrown when a factory can't be found in the registery.
FactoryRegistryException Thrown when a factory can't be found or can't be instantiate.
 

Error Summary
FactoryConfigurationError Deprecated. This error was used by FactoryFinder.
 

Package org.geotools.factory Description

Utility classes which enable dynamic binding to factory implementations at runtime.

Because Geotools core API consists almost exclusively of interfaces (including GeoAPI), factories play a role in how developers use the API. Although the interfaces that are declared in GeoAPI are implemented in various Geotools packages you should not use those classes directly. Instead you should use factories.

J2SE's ServiceRegistry provides a general way (even if it is defined in a subpackage) to instantiate and manage factories (also called providers). Each factory implementation should be declared in directory, usually bundled in every JAR file. For example if a JAR file provides one or more DatumFactory implementations, then it must provide the following file:

META-INF/services/org.opengis.referencing.datum.DatumFactory

with a content similar to the one below:

com.mycompany.MyDatumFactory1
com.mycompany.MyDatumFactory2
com.mycompany.MyDatumFactory3

The ordering is initially unspecified. Users can set an ordering explicitly themselves, or implementations can do that automatically on registration. The AbstractFactory class provides a simple way to setup ordering on registration on the basis of a priority number.

If a user wants a specific implementation, he can iterates through registered ones and pickup the desired implementation himself. An alternative is to bundle the criterions in a map of hints and lets the registry selects an implementation accordingly. This later functionality is not provided by the standard ServiceRegistry, but is provided by Geotools's FactoryRegistry extension. This class extends the service registry API with the following functionalities:

Note that the hints, if provided, don't need to apply directly to the requested factory category. They may apply indirectly through some dependency. A typical example is a request for any GeometryFactory instance, providing that this instance uses a particular CoordinateSequenceFactory implementation.



Copyright © GeoTools. All Rights Reserved.