Jody Garnett a écrit :
> Thanks - one thing we can do is remove the GeoTools 2.1 instructions -
> and the classes they talk about.
Yes.
> Clarification on your Clarification by service you mean the "big ticket"
> items that we usually handle one module at a time? Providing and
> additional CRSAuthorityFactory, defining support for a new DataStore
> etc. How fine grain do you want/need to go?
A "service" was a factory interface. Maybe I used the wrong term. So we have a
singleton FactoryRegistry for managing all CRSAuthorityFactory implementations
no matter which module they come from. This singleton is located in the
referencing module, because it is the core module providing referencing
"services". The same FactoryRegistry singleton is used for managing
DatumAuthorityFactory, CoordinateOperationFactory, etc., but it doesn't have
too. It is up to module implementor choice. I don't think it will make a
difference for the user.
> My concern is that singletons are not "in one spot" - so when I drop
> GeoTools into
> more interesting environments I am going to be up for a murderous
> debugging session.
We have other singletons in the code base (HashMap as static field, etc.),
often
for caching purpose. I guess that the concern is about a central place for
performing system-wide configuration. We have:
- org.geotools.factory.Factories (proposed attempt for factories)
- org.geotools.util.Logging
- Maybe some other that I don't remember right now.
So the concern may be about removing every configuration method from
FactoryFinders (e.g. FactoryFinder.setOrdering(...)) and put them in Factories
instead. The various FactoryFinder in different modules would be nothing less
than type-safe wrappers around their own FactoryRegistry singleton; every
configuration would be done through static methods in Factories. Would it
adress
the concern?
> - How the mapping from parameters to instance is handled (ignoring
> factory) an instance
> may of been provided already by the application, or may only need to be
> created just once
> "EPSG:4326" -> CoordinateReferenceSystem
I not sure to understand... FactoryRegistry or FactoryFinder just provide the
CRSAuthorityFactory instance. The mapping from "EPSG:4326" to
CoordinateReferenceSystem is performed by the CRSAuthorityFactory
implementation
itself (e.g. org.geotools.referencing.factory.epsg.DefaultFactory); this is not
FactoryRegistry job...
> Here is an easy example - right now referencing.FactoryFinder has a
> FactoryRegistry that is used to track CRSAuthrotyFactories. I am moving into
> a environment
> (J2EE) where the DataSource must be provided - this requirement was not know
> when
> referencing.FactoryFinder was produced - it is only introduced by an
> implementation that
> referencing.FactoryFinder picks up on the classpath.
FactoryRegistry or FactoryFinder don't need to be aware of the DataSource.
Every
'FactoryFinder.getFooFactory(...)' methods expect a map of Hints, which is
completly left to Factory implementations.
For the DataSource use case, we added a Hints.EPSG_DATA_SOURCE hint key. We
added this key in the org.geotools.factory.Hints class in order to keep all
keys
in a common place, but the key could really be defined anywhere, including
deeply hiden in a specific module.
When FactoryRegistry lookup for a Factory implementation, it compares the hints
provided by the user to the 'FactoryFinder.createFooFactory(Hints)' method with
the hints declared by a Factory (from the getImplementationHints() method
declared in Factory interface). Simplified pseudo-code of the algorithm used:
public static FooFactory getFooFactory(Hints userHints) {
for (... iterate over all foo factories ...) {
FooFactory candidate = iterator.next();
Hints factoryHints = candidate.getImplementationHints();
if (factoryHints.equals(userHints)) {
return candidate;
}
}
}
So we can have two implementations of referencing.factory.epsg.DefaultFactory.
For one implementation, the value for the Hints.EPSG_DATA_SOURCE hint is
"jdbc/EPSG". For an other implementation, the value may be "jdbc/FOO". If the
user provided a EPSG_DATA_SOURCE hint with value "jdbc/FOO" then the later
implementation will be selected by FactoryRegistry.
If the user hint doesn't match any implementation, for example if the user
provided a EPSG_DATA_SOURCE hint with value "jdbc/FOO2", then FactoryRegistry
(actually the FactoryCreator subclass) will create a new factory instance using
reflection. It will look for a constructor expecting only one argument, Hints.
In the example above, it will invoke the DefaultFactory(Hints) constructor.
> We will *never* know what new implementations require (we cannot have a
> fixed list in the way FactoryRegistery desires).
Right, and we don't need to. The requirements are specified through hints,
which
are fully extensible. FactoryRegistry don't need any change when new hints are
added. This is just new values in a HashMap.
> If I treat this as "glue code" to bind GeoTools together FactoryRegistry
> is a bad choice based on this limitation.
Again there is no limitation regarding the example above (JNDI name for
DataSource to be used by org.geotools.referencing.factory.epsg.DefaultFactory).
Maybe there is other limitation for other use case that I didn't saw, but for
now I don't see any.
>> * Is there other global configuration to provide appart
>> 'add/removeFactoryIteratorProvider()' and maybe 'scanForPlugins()'?
> Setting of JNDI initial context, logging settings
They are not managed by FactoryRegistry, so this is an other topic...
> providing known implementations (to the application) of DataSource,
> CRSAuthorityFactory, GeometryFactory and so on).
I think that this use case is already well covered by current design:
- User create the following in its own application space
(not a geotools global setting):
private static final Hints myApplicationSetting = new Hints();
static {
myApplicationSetting.put(Hints.CRS_AUTHORITY_FACTORY, myOwnCrsFactory);
myApplicationSetting.put(Hints.CRS_GEOMETRY_FACTORY, myOwnGeomFactory);
myApplicationSetting.put(Hints.LENIENT_DATUM_SHIFT, Boolean.TRUE);
myApplicationSetting.put(Hints.EPSG_DATA_SOURCE, "jdbc/MyOwnEPSG");
// etc.
}
void anyUserMethodWantingFactory() {
FeatureFactory f = FactoryFinder.getFeatureFactory(myApplicationSetting);
Feature fe = f.createFoo(...);
// etc.
}
The feature factory will use the user's "myOwnCrsFactory" and
"myOwnGeomFactory", which are propagated through the hints. A different
application using Geotools in the same JVM can have is own application-wide
setting if it define and use its own "myApplicationSetting" in the same way.
Note that the hints is not just about factory dependencies. It is also about
boolean value, name as a string, etc. In brief, everything that could be
specified as argument to a Factory constructor.
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
