cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Design] ContainerManager is under fire--let's find the best resolution
Date Sat, 08 Jun 2002 13:03:52 GMT
Paulo Gaspar wrote:
> 
> About Object instead of Component...

...

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

"classes", if you want to reuse existing 'classes'.

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

You are telling me that instead of doing 

 ConnectionPool pool = new ConnectionPool(...);

you like to do

 ConnectionPool pool = (ConnectionPool) factory.create("connection
pool");

Despite the obvious type unfafetyness introduced, admittedly, this is a
step forward in the control of pooled objects.

Now, you (and Berin) were suggesting that the CM be extended to provide
a single point of contruction control not only for Avalon components,
but also for those legacy objects that might request non-simple
contruction control (such as pooled resources).

I'm still very skeptical this is a good thing to do, it seems to be
blurrying the component concept way too much.

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

Hmmm, I have to think about this some more.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message