db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: org.apache.ojb.broker.util.configuration vs. org.apache.avalon.framework.configuration?
Date Wed, 23 Apr 2003 18:13:57 GMT
Hi Neeme,

Neeme Praks wrote:
> While browsing through OJB source code to find an easy way to write an 
> OJB component for Avalon containers, I can across the following TODO item:
> org/apache/ojb/broker/util/configuration/package.html:
> [snip]
> Todo:
> merge with jakarta commons-configuration API
> [snip]
> While this looks like a sensible idea at first sight, I have a different 
> opinion: OJB should use Avalon framework API interfaces instead of 
> commons configuration API interfaces.

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.

> Why?
> Both OJB and Avalon framework configuration interfaces support 
> "inversion of control" pattern, commons configuration doesn't.
> As a result, it would be quite painless to do the following conversion:
> org.apache.ojb.broker.util.configuration.Configurable ->
>    org.apache.avalon.framework.configuration.Configurable
> easy match, 1-1 mapping
> org.apache.ojb.broker.util.configuration.Configuration ->
>    org.apache.avalon.framework.configuration.Configuration
> here we have some differences:
> 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.

>    String[] getStrings(...); //this could be replaced by Avalon support 
> for child values
> Avalon has additional support for XML conf:
>    attributes, values, namespaces, children.
> org.apache.ojb.broker.util.configuration.ConfigurationException ->
>    org.apache.avalon.framework.configuration.ConfigurationException
> one difference: OJB has protected ConfigurationException(String key, 
> String message), but as this is protected, this should not be an issue.
> org.apache.ojb.broker.util.configuration.Configurator
> This interface has no real equivalent in Avalon and should probably stay 
> with OJB. However, the configurator implementations can probably take 
> advantage of the following avalon helper classes:
> org.apache.avalon.framework.configuration.ConfigurationUtil
> org.apache.avalon.framework.configuration.DefaultConfigurationBuilder
> org.apache.avalon.framework.configuration.DefaultConfigurationSerializer
> 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").

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).

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


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

View raw message