GeoTools, the Java GIS toolkit

I concur.

Near as I can tell the FactoryRegistry implements used by GeoTools seems 
to have no ability to construct implementations on the CLASSPATH using 
user supplied hints. In every case a no argument constructor is used 
(that refers to the global hints).

What the FactoryRegistry implementation does do is check the global 
hints that were used and uses them to store an instance for reuse.

I am going to try a Hack because I am sick of this not working.
- The obvious one is to patch FactoryRegistry to look for the correct 
constructor - I tried and failed
- We could let it make an invalid Factory, then do reflection on the 
instance returned and create a good one - sounds horrible
- Store the user supplied Hints in a ThreadLocal at the FactoryRegistry, 
so we can go with the coding idiom everyone seems to be doing anyways:
>     public PrimitiveFactoryImpl() {
>         this( null );
>     }
>     public PrimitiveFactoryImpl( Hints hints ) {
>         this.crs = (CoordinateReferenceSystem) hints.get( Hints.CRS );
>         this.positionFactory = 
> GeometryFactoryFinder.getPositionFactory(hints);
>        
>         hintsWeUsed.put(Hints.CRS, crs );
>         hintsWeUsed.put(Hints.POSITION_FACTORY, positionFactory );
>     }
>     public Map getImplementationHints() {
>         return Collections.unmodifiableMap( hintsWeUsed ); // so 
> FactoryRegistry does not create duplicates
>     }
The ThreadLocal Hints can be picked up when FactoryRegistry is called 
with *null* hints. When called for the first time we can use the Global 
Hints for the initial value. I may be able to synchronize the factory 
finder and keep the solution there

Cheers,
Jody

Graham Davis wrote:
> I'm trying to create a factory finder for the unsupported geometry 
> module with referencing->GeometryFactoryFinder.java that uses the 
> factory service registry stuff in metadata.
>
> I can't seem to get it to use the Hints I've setup for finding and 
> creating a factory.  It only seems to find the factory if it has a 
> constructor with no parameters, but that is useless because the factory 
> needs a CRS and other things.  Does anyone have any idea of how the 
> Hints are suppose to be used or setup?  I've tried creating a 
> constructor that uses Hints to build the factory, but that isn't found.  
> Only the blank constructor is.  Does anyone know how Hints are meant to 
> be used properly?
>
>

I just found some evidence that this stuff is supposed to work - from 
FactoryCreator (a subclass of FactoryRegistry):
>         /*
>          * No implementation hint provided. Search the first 
> implementation
>          * accepting a Hints argument. No-args constructor will be 
> ignored.
>          * Note: all Factory objects should be fully constructed by now,
>          * since the super-class has already iterated over all factories.
>          */
The mystery gets deeper.
Jody

> I'm trying to create a factory finder for the unsupported geometry 
> module with referencing->GeometryFactoryFinder.java that uses the 
> factory service registry stuff in metadata.
>
> I can't seem to get it to use the Hints I've setup for finding and 
> creating a factory.  It only seems to find the factory if it has a 
> constructor with no parameters, but that is useless because the factory 
> needs a CRS and other things.  Does anyone have any idea of how the 
> Hints are suppose to be used or setup?  I've tried creating a 
> constructor that uses Hints to build the factory, but that isn't found.  
> Only the blank constructor is.  Does anyone know how Hints are meant to 
> be used properly?
>
>

Jody Garnett a écrit :
> Near as I can tell the FactoryRegistry implements used by GeoTools seems 
> to have no ability to construct implementations on the CLASSPATH using 
> user supplied hints. In every case a no argument constructor is used 
> (that refers to the global hints).

This is not true, it work if used as expected. Please lets try to fix your use case.


* You must use the FactoryCreator subclass, not FactoryRegistry.

* You *MUST* write a factory class with a constructor as below:

public class MyFactory extends AbstractFactory {

     private SomeObjectICareAbout someValueICareAbout;

     public MyFactory() {
         this(null); // You could put there any default hints you wish.
     }

     public MyFactory(Hints userHints) {
         someValueICareAbout = userHints.get(Hints.THE_HINT_I_CARE_ABOUT);
         hints.put(Hints.THE_HINT_I_CARE_ABOUT, someValueICareAbout);
     }
}


Again, the hint you care about *MUST* be passed to the AbstractFactory.hints 
map, otherwise it will not work. Put only the hints you care about (do not use 
hints.putAll(userHints)).

	Martin

Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> Near as I can tell the FactoryRegistry implements used by GeoTools 
>> seems to have no ability to construct implementations on the 
>> CLASSPATH using user supplied hints. In every case a no argument 
>> constructor is used (that refers to the global hints).
> This is not true, it work if used as expected. Please lets try to fix 
> your use case.
I agree - I found the code and was starting to debug it yesterday. What 
I found was that in FactoryCreator it was calling super (ie 
FactoryRegistry) and getting the default "no argument" constructor 
returned in all cases. The code that was calling this was set up to 
expect an exception - and only then would it hunt around for the correct 
constructor.

In my understanding there are three steps:
1- it needs the no argument constructor so that the FactorySPI system 
can return an Object (if the user explicitly specified an exact 
implementation it would be found and returned directly
2- It would then ask the object for its class
3- And then finally perform reflection on that class in order to look 
for a constructor that creates hints

Step 1 seems broken; when I commented out step 1 I was able to confirm 
that step 2 and 3 work as expected.

In short we are just looking at a bug; frankly this is very exciting 
since I was having the same kinds of trouble with the referening module 
(but since it is so complicated I was having a hard time isolating the 
problem and communicating with anyone about it).

> * You must use the FactoryCreator subclass, not FactoryRegistry.
check
> * You *MUST* write a factory class with a constructor as below:
Check, it took us a while to figure out that the no argument constructor 
was needed. The code that calls this constructor is a Sun class and 
cannot be "fixed" to look for Hints (ie doing this in a single step).
We implemented the GeoTools Factory interface - it has the 
getImplementationHints method and was suited for our purpose. Do you 
really want us to extend the AbstractFactory?
> Again, the hint you care about *MUST* be passed to the 
> AbstractFactory.hints map, otherwise it will not work. Put only the 
> hints you care about (do not use hints.putAll(userHints)).
Understood; the hints we use (and only the hints we use) are available 
via the getImplementationHints() method on the 'Factory' interface.

Jody

Jody Garnett a écrit :
> In my understanding there are three steps:
> 1- it needs the no argument constructor so that the FactorySPI system 
> can return an Object (if the user explicitly specified an exact 
> implementation it would be found and returned directly

Yes. Note that the no-argument constructor is never invoked explicitly by 
org.geotools.factory.FactoryRegistry. It is invoked by 
javax.imageio.spi.ServiceRegistry.


> 2- It would then ask the object for its class
> 3- And then finally perform reflection on that class in order to look 
> for a constructor that creates hints

There is a missing step:

2.5- It ask for Factory.getImplementationHints() and checks if the hints used by 
the Factory match the hints specified by the users.


> Step 1 seems broken; when I commented out step 1 I was able to confirm 
> that step 2 and 3 work as expected.

I'm not sure that it is broken; It seems to work with the referencing module, 
which uses many hints. Can you point me to a code I could look at?


> We implemented the GeoTools Factory interface - it has the 
> getImplementationHints method and was suited for our purpose. Do you 
> really want us to extend the AbstractFactory?

Right, you don't have to extends AbstractFactory. You can do as you wish as long 
as getImplementationHints() returns all relevant hints, but it must returns 
those hints (not an empty map). The hint must be declared even if its value is 
null. For example if a Factory cares about Hints.COORDINATE_REFERENCE_SYSTEM, 
then we must have something functionnaly equivalent to:

     public Map getImplementationHints() {
         Map hints = new HashMap();
         hints.put(Hints.COORDINATE_REFERENCE_SYSTEM, crs);
         return hints;
     }

even if "crs" is null. Workflow example:

   * A user ask for a GeometryFactory with the following hints:
     userHints.put(Hints.COORDINATE_REFERENCE_SYSTEM, WGS_84);

   * FactoryRegistry scans for GeometryFactory in priority order. If
     it find a GeometryFactory of appropriate class (if a particular
     class was requested), it call its getImplementationHints() method.
     Then there is a choice:

     - If the getImplementationHints() do *not* contains a
       Hints.COORDINATE_REFERENCE_SYSTEM key (no matter if the associated
       value is null or not), then FactoryRegistry said "this factory don't
       care about the CRS. It is suitable for the user needs, since the user
       COORDINATE_REFERENCE_SYSTEM hint will not make any difference for this
       factory". No GeometryFactory(Hints) constructor is invoked since the
       existing factory is considered suitable and returned (as a cached
       factory).

     - If the getImplementationHints() do contains a
       Hints.COORDINATE_REFERENCE_SYSTEM key, then the value for this key
       is compared with the value provided in the "userHints" map. Then there
       is a choice:

       * If the values are equal (and assuming that all other relevant hints
         have been checked in the same way), then the GeometryFactory is
         considered suitable to user needs. No GeometryFactory(Hints)
         constructor is invoked since the existing factory is considered
         suitable and returned (as a cached factory).

       * If the values are not equal, then FactoryFinder continue the search
         for an other GeometryFactory. If no suitable GeometryFactory is found,
         then an exception is thrown. If we are actually using FactoryCreator
         instead of FactoryRegistry, only then the exception is caugh and a
         new factory is created using the GeometryFactory(Hints) constructor.
         This factory is then cached. Next time that a user will ask for a
         GeometryFactory, the new GeometryFactory just created will be one
         more candidate in the process described above.

		Martin

Martin,

The code we are using is found in 
referencing->org.geotools.geometry->GeometryFactoryFinder.java  and we 
have begun adding the Hints constructors to PrimitiveFactoryImpl in the 
unsupported gometry module.

Graham.


Martin Desruisseaux wrote:

> Jody Garnett a écrit :
>
>> In my understanding there are three steps:
>> 1- it needs the no argument constructor so that the FactorySPI system 
>> can return an Object (if the user explicitly specified an exact 
>> implementation it would be found and returned directly
>
>
> Yes. Note that the no-argument constructor is never invoked explicitly 
> by org.geotools.factory.FactoryRegistry. It is invoked by 
> javax.imageio.spi.ServiceRegistry.
>
>
>> 2- It would then ask the object for its class
>> 3- And then finally perform reflection on that class in order to look 
>> for a constructor that creates hints
>
>
> There is a missing step:
>
> 2.5- It ask for Factory.getImplementationHints() and checks if the 
> hints used by the Factory match the hints specified by the users.
>
>
>> Step 1 seems broken; when I commented out step 1 I was able to 
>> confirm that step 2 and 3 work as expected.
>
>
> I'm not sure that it is broken; It seems to work with the referencing 
> module, which uses many hints. Can you point me to a code I could look 
> at?
>
>
>> We implemented the GeoTools Factory interface - it has the 
>> getImplementationHints method and was suited for our purpose. Do you 
>> really want us to extend the AbstractFactory?
>
>
> Right, you don't have to extends AbstractFactory. You can do as you 
> wish as long as getImplementationHints() returns all relevant hints, 
> but it must returns those hints (not an empty map). The hint must be 
> declared even if its value is null. For example if a Factory cares 
> about Hints.COORDINATE_REFERENCE_SYSTEM, then we must have something 
> functionnaly equivalent to:
>
>     public Map getImplementationHints() {
>         Map hints = new HashMap();
>         hints.put(Hints.COORDINATE_REFERENCE_SYSTEM, crs);
>         return hints;
>     }
>
> even if "crs" is null. Workflow example:
>
>   * A user ask for a GeometryFactory with the following hints:
>     userHints.put(Hints.COORDINATE_REFERENCE_SYSTEM, WGS_84);
>
>   * FactoryRegistry scans for GeometryFactory in priority order. If
>     it find a GeometryFactory of appropriate class (if a particular
>     class was requested), it call its getImplementationHints() method.
>     Then there is a choice:
>
>     - If the getImplementationHints() do *not* contains a
>       Hints.COORDINATE_REFERENCE_SYSTEM key (no matter if the associated
>       value is null or not), then FactoryRegistry said "this factory 
> don't
>       care about the CRS. It is suitable for the user needs, since the 
> user
>       COORDINATE_REFERENCE_SYSTEM hint will not make any difference 
> for this
>       factory". No GeometryFactory(Hints) constructor is invoked since 
> the
>       existing factory is considered suitable and returned (as a cached
>       factory).
>
>     - If the getImplementationHints() do contains a
>       Hints.COORDINATE_REFERENCE_SYSTEM key, then the value for this key
>       is compared with the value provided in the "userHints" map. Then 
> there
>       is a choice:
>
>       * If the values are equal (and assuming that all other relevant 
> hints
>         have been checked in the same way), then the GeometryFactory is
>         considered suitable to user needs. No GeometryFactory(Hints)
>         constructor is invoked since the existing factory is considered
>         suitable and returned (as a cached factory).
>
>       * If the values are not equal, then FactoryFinder continue the 
> search
>         for an other GeometryFactory. If no suitable GeometryFactory 
> is found,
>         then an exception is thrown. If we are actually using 
> FactoryCreator
>         instead of FactoryRegistry, only then the exception is caugh 
> and a
>         new factory is created using the GeometryFactory(Hints) 
> constructor.
>         This factory is then cached. Next time that a user will ask for a
>         GeometryFactory, the new GeometryFactory just created will be one
>         more candidate in the process described above.
>
>         Martin



-- 
Graham Davis
Refractions Research Inc.
gdavis@...

Hi Martin:

The problem I found was with the FactoryCreator.getServiceProvider 
method - it starts out ...
> public Object getServiceProvider(final Class     category,
>                                      final Filter    filter,
>                                      final Hints     hints,
>                                      final Hints.Key key)
>             throws FactoryRegistryException
>     {
>         final FactoryNotFoundException notFound;
>         try {
>             return super.getServiceProvider(category, filter, hints, key);
>         } catch (FactoryNotFoundException exception) {
>             // Will be rethrown later in case of failure to create the 
> factory.
>             notFound = exception;
>         }
My problem is with line 113 (ie return super.getServiceProvider( ... ); )

In every case we were either directly returning the object provided by 
the no argument constructor, or we were producing a 
FactoryNotFoundException - at which point the later code would not work 
either (as it needs the no argument constructor to work so it gets an 
object back in order to get a Class to perform reflection on).

To "fix" this problem I was experimenting with something like this:
>         final FactoryNotFoundException notFound;
>         Factory found;
>         try {
>             found = (Factory) super.getServiceProvider(category, 
> filter, hints, key);
>         } catch (FactoryNotFoundException exception) {
>             // Will be rethrown later in case of failure to create the 
> factory.
>             notFound = exception;
>         }
..
> if( found != null ){
>             return found;
>         }
>         else if( notFound != null ){
>             throw notFound;
>         }
>         else {
>             throw new FactoryNotFoundException("Could not locate 
> instance of "+category)
>         }
Using this kind of code I was able to get both:
- the no argument constructor to be called (required so an 
implementation would be found)
- the hints constructor to be called

Debugging this is where I left off Friday,
Jody

> Jody Garnett a écrit :
>> Near as I can tell the FactoryRegistry implements used by GeoTools 
>> seems to have no ability to construct implementations on the 
>> CLASSPATH using user supplied hints. In every case a no argument 
>> constructor is used (that refers to the global hints).
> * You must use the FactoryCreator subclass, not FactoryRegistry.

Jody Garnett a écrit :
> In every case we were either directly returning the object provided by 
> the no argument constructor, or we were producing a 
> FactoryNotFoundException - at which point the later code would not work 
> either (as it needs the no argument constructor to work so it gets an 
> object back in order to get a Class to perform reflection on).

This is true - a no-argument constructor must exists and the factory must be 
registered in the META-INF/services/ directory in order to work. The no-argument 
constructor should provides default hints for the most common (or most "strict") 
cases.

It will not prevent the GeometryFactory(Hints) constructor to be invoked later, 
because FactoryRegistry should detect that the GeometryFactory created with the 
no-arg constructor don't have 'Factory.getImplementationHints()' matching user's 
request.

Davis Graham a écrit :
> The code we are using is found in referencing->org.geotools.geometry->GeometryFactoryFinder.java
 > and we have begun adding the Hints constructors to PrimitiveFactoryImpl in 
the unsupported gometry module.


I see a problem in PrimitiveFactoryImpl. The no-argument constructor do not put 
anything in the hintsWeUsed map. Consequently, ReferencingFactory believes that 
PrimitiveFactoryImpl do not care about any hints, so the PrimitiveFactoryImpl 
instance is always suitable no matter what are user hints.

Suggested fix:

* Rename "hintsWeUsed" by "hintsWeCareAbout" or something like that;
   this is not the same thing.

* Modify the PrimitiveFactoryImpl(Hints) constructor so it accepts
   a null Hints argument. If no hints are provided, use some default
   (probably EPSG:4326 for the CRS...)

* Implements the PrimitiveFactoryImpl() constructor as below:

       this(null);

The important point is that the PrimitiveFactoryImpl() constructor must put, 
directly or indirectly, some Hints.CRS and Hints.WHATEVER keys in the 
"hintsWeCareAbout" map, no matter if the value are null or anything else.

	Martin

Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> In every case we were either directly returning the object provided 
>> by the no argument constructor, or we were producing a 
>> FactoryNotFoundException - at which point the later code would not 
>> work either (as it needs the no argument constructor to work so it 
>> gets an object back in order to get a Class to perform reflection on).
> This is true - a no-argument constructor must exists and the factory 
> must be registered in the META-INF/services/ directory in order to 
> work. The no-argument constructor should provides default hints for 
> the most common (or most "strict") cases.
>
> It will not prevent the GeometryFactory(Hints) constructor to be 
> invoked later, because FactoryRegistry should detect that the 
> GeometryFactory created with the no-arg constructor don't have 
> 'Factory.getImplementationHints()' matching user's request.
So that is what is supposed to throw the FactoryNotFoundException 
exception? I hate seeing exceptions used for flow of control? Seriously 
is that what is expected to happen? Or am I reading the code wrong?
> > and we have begun adding the Hints constructors to 
> PrimitiveFactoryImpl in the unsupported gometry module.
>
> I see a problem in PrimitiveFactoryImpl. The no-argument constructor 
> do not put anything in the hintsWeUsed map. Consequently, 
> ReferencingFactory believes that PrimitiveFactoryImpl do not care 
> about any hints, so the PrimitiveFactoryImpl instance is always 
> suitable no matter what are user hints.
>
> Suggested fix:
>
> * Rename "hintsWeUsed" by "hintsWeCareAbout" or something like that;
>   this is not the same thing.
I see, so we need to indicate what assumptions were made by default; so 
the FactoryRegistry can detect that we ignored the user provided hints?
> The important point is that the PrimitiveFactoryImpl() constructor 
> must put, directly or indirectly, some Hints.CRS and Hints.WHATEVER 
> keys in the "hintsWeCareAbout" map, no matter if the value are null or 
> anything else.
So I am still missing the step where this inconsistency is discovered? 
Can you confirm that we *must* expect a FactoryNotFoundException to be 
thrown at the start of FactoryCreator.getServiceProvider (where it calls 
super?).

Jody

I've implemented Martin's suggestions (in positionfactory, since that is 
the most basic factory and I'm trying to test with that now to make sure 
the factory finder stuff works as it should).  It still can't find my 
factory.

I've commited my recent changes, you can see them in:

- org.geotools.geometry.iso.PositionFactoryImpl
- I'm running a test here:  
org.geotools.geometry.iso.primitive.PrimitiveGeometryBuilderTest.java 
(rename the text case to remove the "x" so it runs.. I added the x so it 
wouldn't run and cause build errors for others when I committed it).

Is there still something I'm missing Martin?  I can't seem to figure out 
why it won't find my factory.

Graham.


Jody Garnett wrote:

> Martin Desruisseaux wrote:
>
>> Jody Garnett a écrit :
>>
>>> In every case we were either directly returning the object provided 
>>> by the no argument constructor, or we were producing a 
>>> FactoryNotFoundException - at which point the later code would not 
>>> work either (as it needs the no argument constructor to work so it 
>>> gets an object back in order to get a Class to perform reflection on).
>>
>> This is true - a no-argument constructor must exists and the factory 
>> must be registered in the META-INF/services/ directory in order to 
>> work. The no-argument constructor should provides default hints for 
>> the most common (or most "strict") cases.
>>
>> It will not prevent the GeometryFactory(Hints) constructor to be 
>> invoked later, because FactoryRegistry should detect that the 
>> GeometryFactory created with the no-arg constructor don't have 
>> 'Factory.getImplementationHints()' matching user's request.
>
> So that is what is supposed to throw the FactoryNotFoundException 
> exception? I hate seeing exceptions used for flow of control? 
> Seriously is that what is expected to happen? Or am I reading the code 
> wrong?
>
>> > and we have begun adding the Hints constructors to 
>> PrimitiveFactoryImpl in the unsupported gometry module.
>>
>> I see a problem in PrimitiveFactoryImpl. The no-argument constructor 
>> do not put anything in the hintsWeUsed map. Consequently, 
>> ReferencingFactory believes that PrimitiveFactoryImpl do not care 
>> about any hints, so the PrimitiveFactoryImpl instance is always 
>> suitable no matter what are user hints.
>>
>> Suggested fix:
>>
>> * Rename "hintsWeUsed" by "hintsWeCareAbout" or something like that;
>>   this is not the same thing.
>
> I see, so we need to indicate what assumptions were made by default; 
> so the FactoryRegistry can detect that we ignored the user provided 
> hints?
>
>> The important point is that the PrimitiveFactoryImpl() constructor 
>> must put, directly or indirectly, some Hints.CRS and Hints.WHATEVER 
>> keys in the "hintsWeCareAbout" map, no matter if the value are null 
>> or anything else.
>
> So I am still missing the step where this inconsistency is discovered? 
> Can you confirm that we *must* expect a FactoryNotFoundException to be 
> thrown at the start of FactoryCreator.getServiceProvider (where it 
> calls super?).
>
> Jody



-- 
Graham Davis
Refractions Research Inc.
gdavis@...

Jody Garnett a écrit :
> So that is what is supposed to throw the FactoryNotFoundException 
> exception? I hate seeing exceptions used for flow of control? Seriously 
> is that what is expected to happen? Or am I reading the code wrong?

This is what is expected to happen. I agree that using exceptions for control 
flow is usually deprecated. In this particular case, the exception has some 
value since we keep it around in order to rethrow it if FactoryCreator failed.

> I see, so we need to indicate what assumptions were made by default; so 
> the FactoryRegistry can detect that we ignored the user provided hints?

??? I'm not sure to understand what you means. We don't ignore user provided 
hints. We just pick up the one that are relevant to the factory.

	Martin

Martin Desruisseaux wrote:

>
> ??? I'm not sure to understand what you means. We don't ignore user 
> provided hints. We just pick up the one that are relevant to the factory.
>
>     Martin
>

I think the issue is we don't see where the hints get used to find or 
create a factory.  Going through the debugger with the test case I 
emailed in the last email, we don't see anywhere that this happens.

-- 
Graham Davis
Refractions Research Inc.
gdavis@...

Graham Davis a écrit :
> I've commited my recent changes, you can see them in:
> 
> - org.geotools.geometry.iso.PositionFactoryImpl

The constructor implementation seems good.

But I noticed that org.geotools.geometry.iso.PositionFactoryImpl is declared in 
META-INF/services/org.geotools.geometry.iso.PositionFactory. Don't you means 
META-INF/services/org.opengis.geometry.PositionFactory? This is the factory that 
GeometryFactoryFinder is looking for.


> - I'm running a test here:  
> org.geotools.geometry.iso.primitive.PrimitiveGeometryBuilderTest.java 

will look if the above doesn't work...

	Martin

Martin Desruisseaux wrote:

> But I noticed that org.geotools.geometry.iso.PositionFactoryImpl is 
> declared in 
> META-INF/services/org.geotools.geometry.iso.PositionFactory. Don't you 
> means META-INF/services/org.opengis.geometry.PositionFactory? This is 
> the factory that GeometryFactoryFinder is looking for.

I don't seem to have that error.  But yes it should be as you remarked.

-- 
Graham Davis
Refractions Research Inc.
gdavis@...

Sorry, I DO have that in my files.  Is that not how it is suppose to be 
(declaring implementations, not interfaces)?

Graham.


Graham Davis wrote:

> Martin Desruisseaux wrote:
>
>> But I noticed that org.geotools.geometry.iso.PositionFactoryImpl is 
>> declared in 
>> META-INF/services/org.geotools.geometry.iso.PositionFactory. Don't 
>> you means META-INF/services/org.opengis.geometry.PositionFactory? 
>> This is the factory that GeometryFactoryFinder is looking for.
>
>
> I don't seem to have that error.  But yes it should be as you remarked.
>


-- 
Graham Davis
Refractions Research Inc.
gdavis@...

Graham Davis a écrit :
> Sorry, I DO have that in my files.  Is that not how it is suppose to be 
> (declaring implementations, not interfaces)?

The filename must be the fully qualified interface name. So the filename should 
be META-INF/services/org.opengis.geometry.PositionFactory

The content of this file declare implementations. So the file should contains a 
single line org.geotools.geometry.iso.PositionFactoryImpl

	Martin

I see the problem now (the file name has is slightly wrong).  Fixing 
that seems to have fixed the problem!  Thanks Martin!

Graham.


Martin Desruisseaux wrote:

> Graham Davis a écrit :
>
>> Sorry, I DO have that in my files.  Is that not how it is suppose to 
>> be (declaring implementations, not interfaces)?
>
>
> The filename must be the fully qualified interface name. So the 
> filename should be META-INF/services/org.opengis.geometry.PositionFactory
>
> The content of this file declare implementations. So the file should 
> contains a single line org.geotools.geometry.iso.PositionFactoryImpl
>
>     Martin



-- 
Graham Davis
Refractions Research Inc.
gdavis@...