Hi Martin:
Just a quick reply for this morning (I am focused on GeometryFactory
implementation right now). You answered some of my misunderstandings (ie
"Service" is just as good a name as "Factory" or "Provider" I just want
to understand what you intended).
If I understand correctly:
- we can have a "one way" declaration of managed services in a
FactoryRegistry
- and "Hints" are used to pass in configuration for the factory creation
HINTS
--------
"EPSG/Authorty"=A datasource instance
|
V
A Registry
--------------------
DatumAuthorityFactory ---> list of instances from classpath
CRSAuthortyFactory ---> epsg-oracle, epsg-hsql, epsg-wkt
etc...
This should be the way things stand now; when looking up a CRSAuthority
for a given set of hints that includes a DataSource we will get back a
list of all instances that were able to handle (or ignore) the provided
hint.
The situation I keep failing to describe is the "cross talk" between
factory registries (where information needs to be handed off between
factory registries), imagine a second FactoryRegistry who's job it is to
produce a DataSource; I would not like to look things up in one
FactoryRegistry (for connect to my DataSource) and then assemble that
DataSource into a Hint in order to look things up in another
FactoryRegistry.
HINTS
--------
connection parameters
|
V
B Registry
--------------------
DataSource ---> process list of ways geotools knows to produce a
datasource
HINTS
--------
"EPSG/Authorty"=instance from B Registry
|
V
A Registry
--------------------
CRSAuthortyFactory ---> epsg-oracle using EPSG/Authorty hint
etc...
For starters it is too much work (GeoTools is forcing me to glue things
together) and I do not want to have to change my source code as
implementations have new requirements (poor isolation). So an automated
system is preferable.
DEFAULT CONTAINER
----------------------------
1 DataSource ---> created from list: JNDIDataSourceProducer,
ParameterDataSourceProducer
2 CRSAuthority ---> created from: epsg-oracle(using datasource)
3 DataStore --> created using a data source
CUSTOM CONTAINER (forward example)
-----------------------------------------
1 DataSource ---> oracle connection provided by application
2 CRSAuthority ---> epsg-oracle attached to provided datasource
3 DataStore --> attached to provided datasource
CUSTOM CONTAINER (both ways)
-----------------------------------------
2 DataSource ---> published by DataStore connection
3 CRSAuthority ---> epsg-oracle attached to provided datasource
1 DataStore --> connects to oracle using prameters
I am not sure these examples are any good :-(
In anycase good to make some progress this week - I will go back to
GeometryFactory for now.
Jody
> 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
