Chris Holmes wrote:
I need to learn about inversion of control. Do you think it'd be useful for geoserver? A bunch of people I respect a lot have been highly recommending the spring framework, which I think is all about IoC. It might be nice to look into for GeoServer 2.0
As mentioned in this article: <http://www.martinfowler.com/articles/injection.html> inversion of control is kind a lame name.
It is really something all frameworks do, it is only an issue in the J2EE world because so many frameworks do it badly. There are many forms of control, some of them GeoServer "inverts" already.
Note the FactoryFinder idea in geotools is a "inversion" of control. The FactoryFinder reads the META-INF directory to allow
GeoServer to discover additional datastores from the classpath environment.
Spring, PicoContainer and so on do the same thing in the J2EE space. Often used to allow the Model View Control parts to find each other, we do the same thing in GeoServer by stuffing the "singleton" instances into the Servlet Container and forcing them to hunt each other down at runtime. We did this to allow proper initialization and cleanup.
Where PicoContainer and friends step in is with the following problem. Right now GeoServer WFS needs to "know" about GeoServer Data (as in actually directly import that class, so it can talk to the instance held by the container.
The Validation plugin however keeps things at arms length - it only uses GeoServer Data by way of a Geotools interface called Repository. Thus *any* implementation of Repository could be used. You can see the similarity with Factory Finder.
The other problem is that we had to define an explicit startup order (Data starts before WFS etc...). Often a good container will figure this stuff out for you.
Please read that Folwer article above and get back to me.
Jody