cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [Design] ContainerManager is under fire--let's find the best resolution
Date Sat, 08 Jun 2002 14:03:08 GMT
Stefano Mazzocchi wrote:

>You are telling me that instead of doing 
>
> ConnectionPool pool = new ConnectionPool(...);
>
>you like to do
>
> ConnectionPool pool = (ConnectionPool) factory.create("connection
>pool");
>  
>
Yuck.  

Better:
ConnectionPool pool = (ConnectionPool) factory.create( 
ConnectionPool.class );

>Despite the obvious type unfafetyness introduced, admittedly, this is a
>step forward in the control of pooled objects.
>  
>
I prefer subclasses.  Granted I don't have intimate knowledge of that 
code yet, but the above signature
gives me chills.

>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.
>  
>
I think you're right.

>  
>
>>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.
>>    
>>
+1 - which a generic factory can't do.  

ConnectionPool = ConnectionPoolFactory.create();
ConnectionPool = 
(ConnectionPool)factory.create(ConnectionPoolFactory.getInstance());

I'm of the general opinion that you know your right when you don't have 
to cast.  (with only a million
exceptions to the rule but as a general principal its sound).

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

-Andy


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


Mime
View raw message