avalon-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 Mon, 17 Jun 2002 21:22:15 GMT
Paulo Gaspar wrote:
> 
> Sorry for the REALLY LATE answer. I have been a bit away:
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > Sent: Saturday, June 08, 2002 3:04 PM
> >
> > 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'.
> 
> Stefano, if I use them as components, why do I have to keep calling them
> classes. As far as I can see they were already used as Components before
> being integrated into a framework.
> 
> Now, I can accept that I am wrong... if you just tell me WHY!
> 
> Explain me the vocabulary model you use and I might adopt it.

If it was possible to have Avalon hook into the java object creation
mechanism, than 'component == class', unfortunately, this is not
possible.

I call an 'avalon component' something that implements avalon classes
and it is created and managed with the avalon lifecycle model.

A class is something that doesn't do that. (note: if you instantiate an
avalon component with 'new', then it's not a component anymore, it's
downgraded at a class in my terminology)

This is why lookup() returned 'Component': it was a way to tell you that
what was returned was something that went thru the avalon lifecycle.

Conceptually, I still don't like the change between Component and
Object, but I *do* understand the value of usability so I'm not
deadlocking the process with stubborn -1s on this.

> > > 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");
> 
> Not really.
> 
> We are talking about:
> 
>   ConnectionPool pool = (ConnectionPool)
>       myComponentManager.lookup("ConnectionPool", "myConnectionPool")
> 
> or something like that. But behind the scenes there is a component
> "factory" that both creates/returns an usable component instance AND
> defines its life style. Actually, this "factory" is a replacement for
> the Avalon's current ComponentHandler.
> 
> The big difference for the current Avalon model is that you are able to
> define a custom "ComponentHandler" for each role and that the
> "ComponentHandler" is the one defining the lifestyle, not the marker
> interfaces of the Component.
> 
> In my framework the "ComponentHandler" must say something about the
> lifestyle to the "ComponentManager" because my CM's component tracking.
> (The component tracking allows th CM to release all the components used
> on a "request", or all the components still "away" on shutdown.)
> 
> > 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).
> 
> Well, it is not really the CM. The CM just keeps the whole thing together
> hiding to the user the uglies of component creation/management.
> 
> > I'm still very skeptical this is a good thing to do, it seems to be
> > blurrying the component concept way too much.
> 
> Why?

explained above. But again, I'm not stopping this from happening if you
see uses for it.
 
> > > 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.
> 
> Did yo ualready?
> =;o)

yes, I did :)

-- 
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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message