db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: ojb 1.1 ideas and proposals
Date Tue, 13 Jul 2004 13:06:31 GMT
Brian McCallister wrote:

> Defaults for primitives should be defined in the component, I fully 
> agree.
> I personally am a big fan of pico (type 3/constructor injection), but 
> it is usually easier to retrofit designs to something like Spring 
> (type 2/setter injection (though as Rod has reminded me on more than 
> one occasion, it does type 3/constructors at least as well as Pico)).
> One of the nice things about the lightweight containers is the the 
> dependency on the container is very small. If we said "we will 
> configure components via Spring by default" switching to Pico is 
> pretty trivial -- there is no code dependency on the container, just 
> configuration.
> I use Pico at work, it is very nice. I have used Spring, but not built 
> anything really big with it. The key thing is that you want to let the 
> container manage the components. You really want to do this. It is 
> tempting to build service lookups into things, but try hard to avoid 
> it and let the container provide it in the constructor (or via a bean 
> setter).
> You get a lot of benefits in terms of help making clean and 
> maintainable code -- dependencies are made very explicit. Swapping out 
> implementations of components, swapping out configuration techniques, 
> managing component life cycles, etc all are pretty handily done in 
> general.
> Drawback is when you have a *lot* of components the configuration can 
> get hairy. We don't have a lot of components though =)

Well, then I think it should be these steps:

* identify configurable components and their properties (from 
OJB.properties, OJBConfiguration.java etc.)
* place default values into the components, and add accessors and 
constructors (if possible) that can be used by IoC containers
* replace configuration implementation by basic Configurator that reads 
OJB.properties and uses the accessors directly (via reflection, no 
external dependencies)
* add optional configuration implementation using Pico
* add a reference guide that explains the configuration possibilities 
(basic, at runtime, using Pico/Spring, using service look e.g. EJB)

Some restructuring of the lib folder seems to be useful then:

* sort libraries that are not always required into subfolders for ext 
(ODMG, JDO if any), compile (Ant etc.), xdoclet, opt (Pico etc.)

This should make it easier for users to determine which libraries are 
required. Also, for jars that we cannot distribute (e.g. j2ee, jdo) I 
can add readme's into the folder stating where to get the libs.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message