|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Base interface for Geotools factories (i.e. service discovery).
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
(or its Geotools extension FactoryRegistry
) is selected as a container for services,
then factory implementations should be declared as below (select only one way):
FactoryRegistry.scanForPlugins()
will be invoked.ServiceRegistry.registerServiceProvider(java.lang.Object)
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 datum factory hint, being passed to a datum authority factory so that all datum created from an authority code will come from the supplied datum factory.
An application supplied a FeatureFactory
(ensuring all
constructed features support the interface), being passed to a
FeatureTypeFactory
so that all
constructed will produce features supporting the indicated interface.
As seen in those examples this concept of a hint becomes more interesting when the opperation 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.
Hints
,
FactoryRegistry
Method Summary | |
java.util.Map |
getImplementationHints()
Map of hints (maybe unmodifiable) used by this factory to customize its use. |
Method Detail |
public java.util.Map getImplementationHints()
FactoryUsingVolatileDependencies
).
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; 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 key set 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 compares
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 datum authority factory uses an ordinary datum factory, 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(Hints.DATUM_FACTORY, datumFactory);
return hints;
|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |