Re: [Geotools-devel] fun with epsg-hsql

[Jody G. <jga...@re...>]

I got a couple of ideas; but the first one is "low stress"...
1. Reduce FatorySPI use to *just* service discovery ... so an 
AuthorityFactoryServiceProvider
2. Have create methods on AuthorityFactoryServiceProvider to create the 
existing AuthorityFactory instances
3. The AuthorityFactoryServiceProvider can cache and recycle instances 
if needed

This is to simplify the problem so we can explore the various plug-in 
models with out tearing our hair out (I don't think either of us have 
much left?).

Martin Desruisseaux wrote:
> Hello Jody
>
> Jody Garnett a écrit :
>> Martin are you still interested in breaking apart the "service 
>> discovery" use of factory spi form the management of factory instances? 
> It is a good time to revisit the factory system since I'm in cleaning 
> stage right now. I'm sorry that it caused you so much pain with 
> Eclipse classloading. 
I don't think it was you; I think it is just us pushing the envelope of 
what Java is capable of years before really good systems were set up.
> However I don't know yet what a replacement would look like. Do you 
> have any idea?
I have several thoughts we can explore...

In the "library should not force a technological direction on a client 
application" corner:
- We may be able to trade some of the "auto wiring" we currently enjoy; 
for some configuration steps similar to GeoTools.init - a bold decision 
but one that may be worthwhile
- There are a bazillion containers that can handle the wiring (and even 
the auto wiring) given nice clean factories with their dependencies 
advertised - this may just allow automation of the configuration step 
mentioned above

In the "library needs a plug-in system" corner:
- OSGi is the obvious one; there are two competing JSRs in the pipe 
right now and they are already working on compromise. Whatever solution 
emerges will need
to deal with a growing body of OSGi based applications.
- Spring has gotten *very very* good at being used inside a library and 
not inflicting unwanted interfaces and so on into client code (it was 
one of their funded technical directions for Spring 2.5).

Those two may amount to the same thing:
- Spring has seen the writing on the wall and is supporting OSGi at some 
level
- Spring is good about isolating your code from subsystems like OSGi (or 
whatever that othe JSR is)
- Spring is just another one of those bazillion containers that handle 
wiring

In anycase let us get 2.5.x safely branched and we can work on this 
together.
Jody