db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeme Praks <ne...@apache.org>
Subject Re: org.apache.ojb.broker.util.configuration vs. org.apache.avalon.framework.configuration?
Date Wed, 23 Apr 2003 20:38:55 GMT
Hi Thomas!

Thomas Mahler wrote:

> I think it was me who wrote this todo item. My idea was to include 
> some of the OJB configuration ideas into commons-configuration.
> I did not intend to replace OJB configuration with commons-configuration.
>
> I just wanted to contribute the OJB config stuff to a wider public, as 
> I thought that is a nicely designed piece of code. 

Ok, in that case this discussion is not that much relevant... I just 
understood that the direction would be to have a dependancy on 
commons-configuration and in that case, the dependancy should rather be 
on avalon-framework...

>> Avalon is missing:
>>    Class getClass(...); //this seems like an implementation detail, 
>> why is this exposed in the interface?
>
> We use the OJB.properties a lot to specify implementation classes. 
> Thus it's convenient to have this method in the public interface. 

ok, makes sense in that case.

>> If you would be interested, then I could try to convert OJB to use 
>> Avalon interfaces (or maybe after 1.0)? If not, then I will write 
>> some glue code to adapt avalon configuration to OJB interfaces.
>
>
> Before replacing the OJB config stuff with something different I'd 
> like to hear some more reasons (apart from "it's possible").

True, very much true. No need to fix something that isn't broken ;-)

> The OJB configuration is a very simple piece of code, but it does 
> everything we need. So why should we replace it. This will add 
> complexitity, another dependency to an external jar (by the way, how 
> big is the avalon.jar that we need).

The framework jar is quite small (22919 bytes), as it contains mainly 
interfaces and some abstract helper classes. The listing of the contents 
of the jar is attached.

> So we need some good arguments why we should do this. What is there in 
> Avalon, that we cannot do with the OJB. 

ok, some benefits:
1. if we just use the framework API jar, then:
* replace or extend configuration interfaces with avalon interfaces: 
makes it easier to avalonize OJB, to wrap it in an avalon component (my 
goal)
* replace or extend logging interfaces with avalon interfaces: same 
argument as above
* and some "soft" benefits also: both of these also promote code reuse 
and intra project collaboration in Apache ;-)

2. if we would take it a bit further, then we could:
* refactor OJB to use some lightweight embeddable avalon container (like 
fortress) for component management: this could possibly make OJB less 
complex and easier to understand. And quite much of the code in OJB 
seems to be dealing with component management (and using the same 
principles as Avalon), so there seems to be quite a bit of overlap...

But still, why should we fix something that isn't broken.
Even if this convergence is going to happen eventually, I envision that 
the process will look something like this:
1. write glue code to wrap OJB as avalon component, reusing as much 
avalon features as possible to make things cleaner and easier to understand
2. see, if the avalon component version of OJB could be a drop-in 
replacement for the "real" OJB by embedding some lightweight container
3. compare the two implementations and see if there are any benefits 
from the Avalon approach

Only after this evaluation process can we say if OJB should start 
messing with Avalon or not. Meanwhile, I will proceed to implement the 
first point and we'll see what comes out of that... as OJB seems to have 
been built with the same principles in mind as Avalon, then this should 
be quite an easy exercise... much easier than with Torque, that has 
static code all over the place...

Rgds,
Neeme

Mime
View raw message