The first utility class we have is helpfully called
GeoTools. This class is used to configure the library for your application.
It also provides the version number of the library, in case you want to check at runtime.:
GeoTools.getVersion(); // Example 15.0
Hints are used to configure the GeoTools library for use in your application. The value provided by
GeoTools.getDefaultHints() can be configured as part of your application startup:
Hints.putSystemDefault(Hints.ENTITY_RESOLVER, NullEntityResolver.INSTANCE); Hints.removeSystemDefault(Hints.ENTITY_RESOLVER);
Hints are similar to a
GeoTools.Key instances each provide javadocs, and some control over the values that may be used. For example the
Hints.ENTITY_RESOLVER values must be an instance of
By contrast Java system properties are similar to a
Map<String,String> and may be specified programmatically or on the command line. The following bindings to system properties are defined (each as static constants in the
The bound system properties can also be used to configure Hints:
// Allow access to local dtd and xsd files System.getProperties.put(GeoTools.ENTITY_RESOLVER, "org.geotools.util.NullEntityResolver"); Hints.scanSystemProperties();
Increasingly GeoTools is being used in carefully managed plug-in systems such as Eclipse or Spring. In order to allow GeoTools to locate its own plug-ins you may need to configure the
GeoTools class with additional class loaders provided by your environment.:
GeoTools.addClassloader( loader );
Out of the box GeoTools searches on the
CLASSPATH available, in order to find plug-in and wire them into the library. It does this by looking in the jar’s
META-INF/services folder which lists plug-in classes.
In rare cases, such as OSGi plug-in system, adding additional jars to the
CLASSPATH is not enough. OSGi blocks access to the
META-INF/services folder. In these cases you will need to provide access to the classes yourself.:
GeoTools.addFactoryIteratorProvider( provider );
To configure GeoTools to look up services in a specific context use the following:
GeoTools.init( context ); // JNDI configuration
For JNDI lookup GeooTools uses:
DataSource dataSource = (DataSource) GeoTools.jndiLookup(name);
jndiLookup(String) is to safe lookups by default. The default use of
GeoTools.DEFAULT_JNDI_VALIDATOR ensures only no-schema and java schema lookups are allowed. To relax this policy you may supply your own approach using
When embedding GeoTools in your own application you may wish to configure the library to use a specific
EntityResolver (to access any XML Schema files included in your application, or to restrict access based on security policies).
GeoTools uses a range of XML technologies when implementing both format and protocol support - where possible these are configured based on the
Hints.ENTITY_RESOLVER described above.
To access the configured
parser.setEntityResolver( GeoTools.getEntityResolver(hints) );
GeoTools also includes two
PreventLocalEntityResolver: For use when working with external XML documents, only allows DTD and XML Schema references to remote resources
NullEntityResolver: Placeholder allowing the default
The library uses
PreventLocalEntityResolver by default, if you wish to work with a local XML file (referencing local DTD and XMLSchema) please use the following during application setup:
If you are working in your own application, you can teach GeoTools to use your application logging facilities (rather than Java logging which it uses by internal default).
GeoTools.init() method will do its best to determine which logging implementation your library is using:
This method tries the following:
For more information see LoggerFactory.