cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 22:34:21 GMT
About Object instead of Component...

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, June 07, 2002 12:18 AM
> 
> Gosh, I forgot how strident can become talking about high level
> abstractions... remind me of the good old days when we were discussing
> what later became known as Avalon and Pier and I got such a huge fight
> for a simple method.
> 
> ihihih, discussing such high-level abstractions can get really nasty
> ego-wise :)
> 
> Berin Loritsch wrote:
> > 
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > >
> > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> blah blah blah
> 
> Let's clear up the table.
> 
> Berin is proposing a better CM and I like it more than what Avalon 4
> has. First of all, it removes that stupid "pass non-exceptional info
> with exceptions" design pattern.
> 
> Ah, BTW, there are *tons* of places where this happens in Avalon,
> please, make sure the above anti-pattern is removed from Avalon 5.
> 
> Then it removes the need for that hacky ComponentSelector, unifying
> approaches.
> 
> Anyway, despite a few issues I'm having (I don't see why we should
> return an Object instead of a Component. That's a component selector,
> not an object selector. There is the Class object for that!) I see it as
> a step forward.
 
I am using a CM similar in concept to the one Berin is proposing for many
months already (I think it will be one year in October) and getting rid of
Component and the other marker interfaces was one of my best decisions.

The Component interface is a major PITA when you want to reuse existing
components. 

Example: if I have a Database Connection Pool independent from Avalon that
I want to use with an Avalon CM, I will have to either:
 - Have and change the DB Pool source in order for it to return Connection
   objects that implement Component;
or
 - Wrap the DataSource objects with my own DataSource that wraps the 
   originaly returned Connection with a proxy Connection that implements
   Component.


With my CM I just need to implement a factory for the DB Connection pool
and the reason I can do that is because my CM uses neither Component nor
other marker interfaces.


In my CM the "factories" make the bridge between the CM/framework and the
components. The "component factories" define:
 - How a component is obtained;
 - How it is released;
 - What is its lifestyle and other "details" that the CM must know.

No marker interfaces.

This makes it MUCH simpler to have a lot of components/parts that are
independent from the CM/framework but that can be used by the CM/framework
with a minimum of coding.

 
> The problem is garbage collection of components.

Here we fully agree. I miss the release() methods.


Have fun,
Paulo Gaspar

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message