Affects Version/s: 2.4-M0
Fix Version/s: None
Currently GeoTools opperates around a number of Singletons ...
- FactoryRegistries (in the varous FactoryFinder and CommonFactoryFinder classes)
- Lots of cached Factories in utility classes such as CRS
And so on.
There is a problem with this - we are suppoed to control the use of Factories with Hints ... but all these implementations do something like the following:
Where "null" seems to mean - I don't care do something smart for me.
This change request is the obvious one - lets do something smart.
We can then change the above code example to:
A couple of "non obvious" consequences:
- Creating the hints based on System propreties will not work in an applet, they will need to explicitly call the init method
- FactoryRegistry "partitions" the factory instances based on the Hints provided
- This means the GeoTools.getDefaultHints() acts as a single singleton for the entire library
- We can change the GeoTools hints returned by getDefaultHints() based on ThreadGroup
- Tthis is how you should do a singleton anyways
- The GeoTools library would then become more safe for use in environments that care about ThreadGroup (like Java EE and Applets)
- We can use the GeoTools class to hold Keys for the library (rather then have them scattered)
- We can use the GeoTools class to hold getVersion() - something that has been requested previously
This change will restore the previous functionality of FactoryFinder (where you could control the library a bit with System properties).