Message-ID: <289163119.5417.1369510925868.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5416_775472566.1369510925868" ------=_Part_5416_775472566.1369510925868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page contains some of my random thoughts on what using a co= ntainer could look like in geotools.
First I think its good to seperate out two main concerns / requirements.=
The first requirement is fulfilled with the FactorFinder system. Which I= must say for most applications works relativley well. However it fails whe= n you get into environments / applications which do fancy class loading tri= cks like breaking out a seperate classloader for each plugin / module. Exam= ples are Eclipse and Geronimo.
The second concern has really not been addressed yet. However luckily th=
e rest of the world has already solved this problem with the notion of a
What these really boil down to is the ability to inject objects in our t= oolkit with alternate implementations of classes or interfaces that they de= pend on. Why is this hard? Well in a layered system like geotools, funtiona= lity and api is separated into layers.
Jody: need an architecture diagram here
Any client of the Geotools toolkit really only gets access to the API in= the top layer, making it hard to configure behaviour at lower layers. This= is really an issue with any layered system.
So you might be saying, how can a magic container fix this for me. And y= ou are right, a container can't do it alone. Really the first step in handl= ing this problem is designing classes and packages and subsystems to be con= tainer friendly. Now different containers offer dependnecy management in di= fferent ways but a fairly common theme is the notion of Inversion of Control. This simple concept really is just say= ing that you the designer of a class are not going to make any assumptions = about which instance of a class to create, let the client do that. The clie= nt can then use a container to make this process easy.
What would a container system look like in geotools?
Do we come up with our own interface, or use an existing one?
Do we come up with our own container interface? Something that might loo= k like the following:
An implementation of this interface could be written for a particular co= ntainer implementation, PicoContainer, Spring, etc... The problem with this= is we have to roll our own api for registering and loading class implement= ations.
The alternative would be to just stick with an implementation that is al= ready out there. A popular choice is PicoContainer which is extremley light= weight and easy to use. The problem with this is that it ties us to a parti= cular container.------=_Part_5416_775472566.1369510925868--