Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40F3CFC7.90900@first.fhg.de>
References: <40F02E7C.3040105@first.fhg.de>
 <F57CDCE4-D3F4-11D8-B95F-000A95782782@forthillcompany.com>
 <40F3CFC7.90900@first.fhg.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B7F3E4CB-D4C5-11D8-B8A3-000D93ADF212@codepuccino.com>
Content-Transfer-Encoding: 7bit
From: "Robert S. Sfeir" <robert@codepuccino.com>
Subject: Re: ojb 1.1 ideas and proposals
Date: Tue, 13 Jul 2004 08:11:06 -0400
To: "OJB Developers List" <ojb-dev@db.apache.org>

FWIW, If we can avoid dependency on more containers/libs it would be 
better.  If it's unavoidable, then it's unavoidable.

R

On Jul 13, 2004, at 8:04 AM, Thomas Dudziak wrote:

> Brian McCallister wrote:
>
>>> Properties can be read from a file (the current schema with 
>>> OJB.properties) and from the System object as well as manipulated 
>>> via generic setProperty/getProperty accessors.
>>
>>
>> Consider also looking at Spring's BeanFactory -- we may be 
>> reinventing things =) Making it basically bean configured opens up 
>> lots of configuration options though -- could be Spring, JMX, Pico 
>> (sort of), XML, etc with much fewer changes, particularly with the 
>> instance based config you talk about.
>
> I read a bit about IoC (btw. there is a good paper by Martin Fowler), 
> and specifically PicoContainer/NanoContainer, and it seems my idea is 
> somewhat similar (sort of a Setter Dependency Injection & 
> Configuration).
> My question is, would it be ok to have the additional dependency to 
> PicoContainer (except when using within Spring or EJB where we would 
> provide alternative configurator implementations)? If yes, then 
> configuration could be realized with PicoContainer, e.g. reading the 
> properties from a file/from System/allow to set via a Configuration 
> object (getProperty/setProperty), which in turn uses PicoContainer to 
> setup the components. Otherwise, we could implement it directly, isn't 
> too difficult for our limited requirements.
>
> I think we should differ in one thing though: default values should be 
> defined within the components, not via external property files or in 
> the Configurator (as it is now), because changes to a component are 
> then local to the component, and there is no coding in the 
> configuration necessary to support new components or changes to 
> existing ones.
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


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