Consider the addition of a [CRS | Operation] factory finder class

the same problem has plagued us, as well. without an entry point into the API, it cannot be used independent of implementation when compiling code. so i added all of the needed get***Factory methods to CommonFactory and created a few missing factories (notably UtilFactory...i cannot be beholden to an InternationalStringImpl nor do i want to force my developers to write their own impl).

there are several classes (actual classes, not interfaces) that we've created that have fallen into GO1Support, since it isn't popular to put them directly in the API spec. one of these is CommonFactoryFinder, which helps me obtain a default implementation of the spec at runtime.

i prefer a single access point rather than multiple, but maybe that's just me. i'm interested to see other views on the issue.

Note that GeoAPI already provides a product-independant way to find implementation, even if it doesn't provides code for that. GeoAPI ask that every implementation are registered using J2SE SPI's mechanism. For example, a CRSFactory from vendor XXX most include the following file in its JAR:

META-INF/services/org.opengis.referencing.crs.CRSFactory

which contains a single line:

com.vendorxxx.referencing.crs.MyCRSFactoryImpl

If an other vendor YYY provides an other implementation for the same factory, he have to bundle the same META-INF/services/... file in its JAR file, but with the following line:

com.vendoryyy.referencing.crs.MyCRSFactoryImpl

There is absolutly no need for any central registry (or put in other way, the central registry is the one managed by J2SE 1.4, not Geotools's one). Just drop any vendor's JAR file in the classpath, and J2SE will automatically find it.

The FactoryFinder class provided in Geotools is really just a wrapper around J2SE 1.4 Service Provider Interface (SPI) registry. If an other vendor ignore org.geotools.referencing.FactoryFinder and use J2SE 1.4 SPI services in its own way, he will find exactly the same implementation.

The opposite is also true: Geotools's FactoryFinder will find any implementation which registered themself in META-INF/services/..., including implementations that totally ignore Geotools.

Unless I missing something, I believe that there is no need for a FactoryFinder implementation in GeoAPI in order to find implementations from any vendor. We may provide a FactoryFinder implementation as a convenience, but it would be just that: convenience. It would not bring a really new capability. GeoAPI already has a vendor-independant way to find any implementations on the classpath.

Or is there something that FactoryFinder should do that I missed? Please comment if I misunderstood the problem.

Regards,

Martin.

The utility of a FactoryFinder class in GeoAPI is not that it performs some super-secret function, but that it performs a well-known function in a well known class in a well known package. It is certainly true that each implementing library can perform discovery functions. It is also true that the Geotools FactoryFinder will detect non-Geotools implementations. This is comforting only if I know that Geotools is on my classpath before using the Geotools implementation to determine which implementations are available. It becomes rather a moot point.

The issue is that I have to know that library X is on my classpath before I ask the "vendor neutral" API for an implementation. Worse, in order to support multiple implementations of the vendor neutral API, I have to explicitly support each vendor's startup mechanism.

Let's assume the worst: I don't know which implementation will be out there, and I don't know how to perform "Discovery" myself. (I understand the part about the services directory in the Jar file. But given that everything is set up correctly, how do I use it?) Is it easy to locate a class which implements a specific interface, or is it convoluted? Can the process be described in 5 steps or less? less than 25 lines of code, or more?

The basic idea is as below. This code use only J2SE's API; there is absolutly no implementation-specific code in that. Most API is available in javax.imageio.spi package. While the package name suggest an image-specific plugin facility, this is really a general framework.

Lets assumes that you are looking for CRSFactory. If this is not true, just replace CRSFactory.class by any other class. Note that "CRSFactory.class" is the GeoAPI class, not the implementation class.

To be run only once (or any time you suspect that a new JAR has been dropped in the classpath):

Iterator it = ServiceRegistry.lookupProviders(CRSFactory.clas, classloader);
while (it.hasNext())

To be run everytime you want to know all CRSFactory implementation registered:

Iterator it = ServiceRegistry.getServiceProvider(CRSFactory.class, false);

Thats all! J2SE standard API only! (note: not all ServiceRegistry methods are static. For simplicity, I ommited that. But it is not a real difficulty). There is really no need to invokes any implementation specific code!!

Geotools's FactoryFinder is nothing else than a convenience utility class wrapping the above code. You can safely ignore it and put the above code directly in yours own application. Then, you have really no dependence at all to Geotools or any other implementation.

This doesn't means that we should not provide a FactoryFinder in GeoAPI as a convenience (this is an open question).

I will note that this idea (while a java standard) does interact strongly with the class loader system (as well it might).

When working in a Eclipse environment each plugin is assigned its own ClassLoader (in order to be sure of what is going on). This does requires some extra thinking over and above the example given above.

Download priority to Minor (ie a known workaround exists)

Ahh, so we can detect the presence of implementations which may be capable of producing CRSes if they were configured. What is the mechanism for determining whether the factory is actually ready to use?

Its depends which kind of configuration we are talking about. For example in the case of CRSFactory, the javax.image.spi.ServiceRegistry automatically creates instances of all classes which have its fully-qualified name listed in the META-INF/services/org.opengis.crs.CRSFactory file. Those factory classes must have a public no-argument constructor. This is the minimal requirements, and is usually enough for many factories.

If a factory must performs a special configuration before to be usable, and if this configuration doesn't need any argument from the user, then there is many possibilities:

• Configuration could be done right in the no-argument constructor,
  or be performed automatically the first time any method is invoked.

• The factory may implements the javax.imageio.spi.RegisterableService
  interface and performs its configuration when it is registered. In
  such case, it have some supplementary information like the
  ServiceRegistry in which it is registered.

In order to know if a factory is ready to use, a 'isReady()' method right in the Factory interface could do the trick.

If the user need to pass arguments, then there is some choices:

• I usually do that through the preferences API (java.util.prefs).
  A great advantage is that the application remember the configuration
  next time it is executed. All we need to do is to agree on the
  preference node name.

• An other possibility is to store the informations in some
  ServiceRegistry subclass and lets the factories fetch those
  informations from the RegistrableService interface.

In any case, I'm not sure that GeoAPI should didacte what arguments for factory configuration should be, since it is very implementation-dependent. I would suggest to first experiment some implementations, and see with experience gained if a need for a standard API for "arguments to be passed to the factory" appears.

I agree about the isReady() method. GeoAPI shouldn't try to constrain the manner in which the factories are constructed.

Let's examine some of the known dependencies for say, CoordinateSystemEPSGFactory...the one backed by the EPSG database.

• It must be specified with a connection to the database.
• The user must have downloaded and installed the database.

The factory can easily know that it's not ready, but it's not easy to specify the parameters needed for construction.

Now what does this do to any factory finders out there? It suggests that they aren't merely looking for any old implementation of a particular authority factory, but only ones which are "ready". If we couple this with other common operations: "Which Set of factories implement this authority?", etc., we can prevent a lot of code duplication.

This isn't restrictive. It works on the interface methods which must be there. It also serves as a bare minimum. Classes can always be extended to provide additional functionality. As you point out, implementors can just ignore this implementation completely and write their own from scratch if they so desire.

Adding a FactoryFinder does not add any dependencies or additional restrictions, but it sure makes it easier to use the library.

I believe that Polexis has a directory for utilities. We could put a FactoryFinder there. My proposal is to not put FactoryFinder in core GeoAPI, but rather in some optional JAR with a small set of utilities. We could migrate some classes from the utilities JAR to the core JAR later if we want, when we feel safe about that.

It remind me that I need to come back on the CVS reorganisation issue...

Since FactoryFinder is not going to be included in next release, uncommit from 1.1. The decision will be delayed to a future release.