Java Doc for Factory.java in  » GIS » GeoTools-2.4.1 » org » geotools » factory » Java Source Code / Java DocumentationJava Source Code and Java Documentation

This interfaces forms the core of the Geotools plug-in system, by which capabilities can be added to the library at runtime. Each sub-interface defines a service. Most services are set up with concrete implementation being registered for use in a service registry, which acts as a container for service implementations.

Service registries don't need to be a Geotools implementation. They can be (but are not limited to) any ServiceRegistry subclass. If the standard ServiceRegistry (or its Geotools extension FactoryRegistry ) is selected as a container for services, then factory implementations should be declared as below (select only one way):

• Register for automatic discovery
• Provide a public no-arguments constructor.
• Add the fully qualified name of the implementation class in the META-INF/services/ classname file where classname is the fully qualified name of the service interface.
• The factory implementations will be discovered when FactoryRegistry.scanForPlugins will be invoked.
• Or register explicitly by application code
• Invoke ServiceRegistry.registerServiceProvider in application code.

In addition, it is recommended that implementations provide a constructor expecting a single Hints argument. This optional argument gives to the user some control of the factory's low-level details. The amount of control is factory specific. The geotools library defines a global class called Hints that is ment as API (i.e. you can assume these hints are supported). Factories may also provide information on their own custom hints as part of their javadoc class description.

• An application supplied a , being passed to a so that all datum created from an authority code will come from the supplied datum factory.

• An application supplied a org.geotools.feature.FeatureFactory (ensuring all constructed features support the Eclipse's IAdaptable interface), being passed to a org.geotools.feature.FeatureTypeFactory so that all FeatureTypes constructed will produce features supporting the indicated interface.

As seen in those examples this concept of a hint becomes more interesting when the operation being controlled is discovery of other services used by the Factory. By supplying appropriate hints one can chain together several factories and retarget them to an application specific task.

The primary purpose of this method is to determine if an existing factory instance can be reused for a set of user-supplied hints. This method is invoked by FactoryRegistry in order to compare this factory's hints against user's hints. This is dependency introspection only; FactoryRegistry never invokes this method for creating new factories.

Keys are usually static constants from the Hints class, while values are instances of some key-dependent class. The must contains at least all hints impacting functionality. While the key set may contains all hints supplied by the user, it is recommended to limit the set to only the hints used by this particular factory instance. A minimal set will helps FactoryRegistry to compare only hints that matter and avoid the creation of unnecessary instances of this factory.

The hint values may be different than the one supplied by the user. If a user supplied a hint as a Class object, this method shall replace it by the actual instance used, if possible.

Implementations of this method are usually quite simple. For example if a uses an ordinary , its method could be implemented as below (note that we should not check if the datum factory is null, since key with null value is the expected behaviour in this case). Example:

 Map hints = new HashMap();
 hints.put(
 , datumFactory);
 return hints;