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 Fri, 25 Apr 2003 08:17:37 GMT
Hi again Neem,

Neeme Praks wrote:
<snip />
> 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.

That's really not much!

>> 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
Don't see so much benefit here. We already support Log4J and 
commons-logging. Other implementations can be plugged without problems.
I'd prefer to talk about functional improvements and not about the 37th 
way of logging.

> * and some "soft" benefits also: both of these also promote code reuse 
> and intra project collaboration in Apache ;-)

Always nice to have...

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

I'm not sure what you mean by component management. What we are doing in 
OJB is to provide a simple interface plugin mechanism. In the 
OJB.properties file we specify which implementation class is to be used.
And then there is an abstract factory class "ConfigurableFactory" with 
concrete subclasses. Those concrete factories use the 
"ConfigurableFactory" infrastructure to read configuration information 
from OJB.properties to serve instances of the correct implementation class.
There is really not much code behind it. So IMO "quite much of the code" 
is not correct. I assume those classes make up 1 - 2 % of the OJB codebase.

 From a discussion some time ago I remember that Avalon could also be 
helpful to enable reconfiguration at runtime. This is something we do 
not have in OJB right now. But to make it work we would need several 
changes to the OJB configured classes als well.

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

That make sense to me!

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

Fine, I'm interested in seeing your results.


> Rgds,
> Neeme
> ------------------------------------------------------------------------
> org/
> org/apache/
> org/apache/avalon/
> org/apache/avalon/framework/
> org/apache/avalon/framework/activity/
> org/apache/avalon/framework/component/
> org/apache/avalon/framework/configuration/
> org/apache/avalon/framework/context/
> org/apache/avalon/framework/logger/
> org/apache/avalon/framework/parameters/
> org/apache/avalon/framework/service/
> org/apache/avalon/framework/thread/
> org/apache/avalon/framework/activity/Disposable.class
> org/apache/avalon/framework/activity/Executable.class
> org/apache/avalon/framework/activity/Initializable.class
> org/apache/avalon/framework/activity/Startable.class
> org/apache/avalon/framework/activity/Suspendable.class
> org/apache/avalon/framework/CascadingError.class
> org/apache/avalon/framework/CascadingException.class
> org/apache/avalon/framework/CascadingRuntimeException.class
> org/apache/avalon/framework/CascadingThrowable.class
> org/apache/avalon/framework/component/Component.class
> org/apache/avalon/framework/component/ComponentException.class
> org/apache/avalon/framework/component/ComponentManager.class
> org/apache/avalon/framework/component/ComponentSelector.class
> org/apache/avalon/framework/component/Composable.class
> org/apache/avalon/framework/component/Recomposable.class
> org/apache/avalon/framework/configuration/Configurable.class
> org/apache/avalon/framework/configuration/Configuration.class
> org/apache/avalon/framework/configuration/ConfigurationException.class
> org/apache/avalon/framework/configuration/Reconfigurable.class
> org/apache/avalon/framework/context/Context.class
> org/apache/avalon/framework/context/ContextException.class
> org/apache/avalon/framework/context/Contextualizable.class
> org/apache/avalon/framework/context/Recontextualizable.class
> org/apache/avalon/framework/context/Resolvable.class
> org/apache/avalon/framework/logger/LogEnabled.class
> org/apache/avalon/framework/logger/Loggable.class
> org/apache/avalon/framework/logger/Logger.class
> org/apache/avalon/framework/parameters/ParameterException.class
> org/apache/avalon/framework/parameters/Parameterizable.class
> org/apache/avalon/framework/parameters/Parameters.class
> org/apache/avalon/framework/parameters/Reparameterizable.class
> org/apache/avalon/framework/service/Serviceable.class
> org/apache/avalon/framework/service/ServiceException.class
> org/apache/avalon/framework/service/ServiceManager.class
> org/apache/avalon/framework/service/ServiceSelector.class
> org/apache/avalon/framework/thread/SingleThreaded.class
> org/apache/avalon/framework/thread/ThreadSafe.class
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message