Thanks Martin:
Reviewing changes now.
And thanks for putting up with me on this one, I am trying to sort these
things out before I run into a deadline (and am forced into a quick
decision).
Martin Desruisseaux wrote:
> Commited the following changes on trunk as of revision 24765:
>
> * Added a new class, org.geotools.factory.Factories, which
> contains only static method that apply to all factories.
> The add/removeFactoryIteratorProvider(...) methods are now
> there and have system-wide effect.
I went to add a single "registry" here for use by all FactoryFinders ...
but now have obviously come up to the reason
for our mis understanding.
org.geotools.referencing.FactoryFinder has the following definition of
registry:
> registry = new FactoryCreator(Arrays.asList(new Class[] {
> DatumFactory.class,
> CSFactory.class,
> CRSFactory.class,
> DatumAuthorityFactory.class,
> CSAuthorityFactory.class,
> CRSAuthorityFactory.class,
> MathTransformFactory.class,
> CoordinateOperationFactory.class,
> CoordinateOperationAuthorityFactory.class}));
I wrote some initial instructions on the developers guide, I see Jesse
has updated them a bit - but the level
of detail required for planning is missing. I am not sure exactly what
is going on and how much is global?
One thing I would do is hid this new FactoryCreator method as a method
of factories .. just so when we figure out
what is going on we have a single location to change.
There are two implementations of FactoryRegistry:
- FactoryCreator - A FactoryRegistry factory registry capable to creates
factories if no appropriate instance was found in the registry.
- Registry - Defines static methods used to access GeometryFactory,
CoordinateSequenceFactory or PrecisionModel factories.
So where does the collection of classes come from? FactoryRegistry
extends ServiceRegistry (from javax.imageio) ... which eventually
populates a internal categoryMap Class -> SubRegistry. Where SubRegistry
takes a class ... and holds a semi ordered list of "providers".
There is lots of interesting stuff here - a ServiceRegistry.Filter that
lets you select which "provider" is good etc... however one thing this
does not do is
allow for additional classes to be added after it is created. The
categoryMap is private and only the constructor adds anything to the map.
And here is our first indication that this thing is intended to be used
as a singleton (in the only used instance IIORegistry):
> /**
> * Returns the default <code>IIORegistry</code> instance used by
> * the Image I/O API. This instance should be used for all
> * registry functions.
> *
> * <p> Each <code>ThreadGroup</code> will receive its own
> * instance; this allows different <code>Applet</code>s in the
> * same browser (for example) to each have their own registry.
> *
> * @return the default registry for the current
> * <code>ThreadGroup</code>.
> */
> public static IIORegistry getDefaultInstance() {
> AppContext context = AppContext.getAppContext();
> IIORegistry registry =
> (IIORegistry)context.get(IIORegistry.class);
> if (registry == null) {
> // Create an instance for this AppContext
> registry = new IIORegistry();
> context.put(IIORegistry.class, registry);
> }
> return registry;
> }
And they have a specific set up method:
> /**
> * Registers all available service providers found on the
> * application class path, using the default
> * <code>ClassLoader</code>. This method is typically invoked by
> * the <code>ImageIO.scanForPlugins</code> method.
> *
> * @see javax.imageio.ImageIO#scanForPlugins
> * @see ClassLoader#getResources
> */
> public void registerApplicationClasspathSpis() {
> // FIX: load only from application classpath
So here is what we got (using IIORegistry as an example):
- ServiceRegistry is designed to be used used as a singleton - one per
thread group
- ServiceRegistry may need a kick to get it going
- The scope of ServiceRegistry can only be set up one at construction time
I am going to think about those limitations and get back to you.
> * Removed the add/removeFactoryIteratorProvider methods from
> FactoryRegistry and CommonFactoryFinder. We are theorically
> allowed to just drop those methods since they were flagged
> with "@since 2.4". However if it break too much code, please
> let me known and I will reinsert them as deprecated methods.
I don't think those have been used yet? GeoServer is the only candidate
to have
noticed them right now? This round of feedback is the uDig team having
its first
attempt at hooking them up.
> * At this time, the new Factories.addFactoryIteratorProvider
> method must be invoked before any factory is used for the
> first time. I need more though in order to allow addition
> later in a JVM live.
Some initial set up will always be required on global settings such as
this, I am not
sure if this is the kind of thing we can do dynamically? The provided
iterators are just
that - iterators. If they are backed onto a dynamic system like OSGi
they will return
more (or less) factories each time they are called.
How dynamic do we need GeoTools to be in this regard?
> Not directly related to FactoryRegistry, but in the same commit:
>
> * Added Hints.EPSG_DATA_SOURCE, which expects a name as a String.
> If not specified, the default is "jdbc/EPSG", as in current
> behavior. We may delete the default if it is a risk of
> confusion.
Thanks - I will get back to epsg-oracle this afternoon (and try and get
the first
error messages out).
Cheers,
Jody
-------------------------------------------------------------------------
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
