You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/06/08 15:03:52 UTC
Re: [Design] ContainerManager is under fire--let's find the best
resolution
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Design] ContainerManager is under fire--let's find the best
resolution
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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
Re: [Design] ContainerManager is under fire--let's find the best resolution
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Can't we just stop crossposting?
Who wants to follow the discussion gets on the Avalon list.
avalon-dev-subscribe@jakarta.apache.org
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Design] ContainerManager is under fire--let's find the best resolution
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> 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).
Stefano, You missed the last discussion we had on the subject
back in January (if I recall correctly). There is a good backgrounder
on the discussion and rationalization of using Object instead of
Component.
The fact of the matter is that if you describe the component
model correctly in terms of parents, children, and peers; then
you don't need to name your compoennts "Component".
Consider the CORBA architecture. It is a component architecture,
as is EJBs. Both of them have their lookup mechanisms--but if we
want to use them directly in an Avalon system, then we have to
be able to either generate proxy objects to implement Component
or we have to modify the original sourcecode. That's a lot of
work to enable the seamless integration with legacy component
systems. CORBA components can be accessed via JNDI just as EJB
components. Why should we place an artificial limitation on
Avalon components that no other public component architecture
does?
The ServiceManager already exists, it represents what we want--
read more than just Cocoon. It isn't going to change, and it
solves a lot of problems without introducing any of serious
consequence.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Design] ContainerManager is under fire--let's find the best
resolution
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design] ContainerManager is under fire--let's find the best resolution
Posted by Paulo Gaspar <pa...@krankikom.de>.
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.
> > 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?
> > 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)
Have fun,
Paulo Gaspar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Design] ContainerManager is under fire--let's find the best resolution
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> 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).
Stefano, You missed the last discussion we had on the subject
back in January (if I recall correctly). There is a good backgrounder
on the discussion and rationalization of using Object instead of
Component.
The fact of the matter is that if you describe the component
model correctly in terms of parents, children, and peers; then
you don't need to name your compoennts "Component".
Consider the CORBA architecture. It is a component architecture,
as is EJBs. Both of them have their lookup mechanisms--but if we
want to use them directly in an Avalon system, then we have to
be able to either generate proxy objects to implement Component
or we have to modify the original sourcecode. That's a lot of
work to enable the seamless integration with legacy component
systems. CORBA components can be accessed via JNDI just as EJB
components. Why should we place an artificial limitation on
Avalon components that no other public component architecture
does?
The ServiceManager already exists, it represents what we want--
read more than just Cocoon. It isn't going to change, and it
solves a lot of problems without introducing any of serious
consequence.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>