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/07 00:18:27 UTC
Re: [Design] ContainerManager is under fire--let's find the best
resolution
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.
The problem is garbage collection of components.
- o -
WARNING: radical changes ahead, this is not for the faint-hearted! YOU
HAVE BEEN WARNED!
Let's make one step back: what is an avalon component?
I'm pretty sure that everybody has a different idea on what this really
is, but here is my personal one:
an avalon components is the implementation of a functional description
[so far, is nothing different from a normal class implementing an
interface]
and exposes behavioral modifiers
This is the difference between an Avalon component and a java class
implementing an interface: the way the class is created.
[the other differences are functional, not conceptual]
In Java, the only way to modify how a class is constructed is to call a
different constructor method. Unfortunately, java doesn't define
"construction prototypes" but only 'functional prototypes' (with
interfaces).
This left the original Avalon designers with one radical solution:
deprecate the use of constructors and create a totally different
construction lifecycle.
First, we thought about creating a ComponentFactory, something like
public class ComponentFactory {
Component createComponent(String componentName);
}
but soon we realized that the ability to separate the concern of
creation from that of use, we could simply create pools of pre-created
objects. So, in that case, createComponent() was a bad name and Factory
too limiting.
This lead to the concept of a ComponentManager, the 'director' of the
'play', where each actor asks the director to indicate what person
performs a particular role in the play, in order to be able to
communicate with it.
The CM is also able to 'instruct' a new actor to perform a particular
role. So, from a design pattern point of view, "Manager extends
Factory".
We didn't think about role collisions: blinded by the 'play metaphor',
we thought that there was no need, on stage, for two actors acting the
same role with dressed up in different colors. On later thought, this is
not true: it is the rule that important carachters in the play has a
'backup'. In that case, an actor might ask not only the role played, but
also the 'hint' (official/backup) to obtain the reference to the other
actor.
So, it makes perfect sense to merge the two aspects into a single CM.
So far so good.
- o -
Two steps back, now.
Before the introduction of automatic garbage collection, everybody
allocated memory, used it and freed it when it was not needed. Failing
to do the last part provided those infamous 'memory leaks' that almost
all programs in the world suffer.
In more abstracted languages where you don't have direct access to the
memory, you don't allocate it directly, but you create an functional
entity (object, for example), you use it, then you dispose it.
This is less error prone because it's more abstract, but still requires
people to know what they are doing and don't forget to dispose those
objects which aren't needed.
Enter garbage collection: at the price of a system overhead, the
programmer is released from the responsibility to provide explicit
disposal for the objects he creates.
You know what? I'm starting to think that the java GC is a gigantic
mistake. Why? simple, it's useless.
A GC continue to skeep thru your object space to look for 'detached'
objects. That's a great implementation, but what if I forgot to 'detach'
those objects?
If GC was that effective, why Java programs leak memory anyway?
Some people believe that Java is inherently safer than C because it has
garbage collection that prevents people from shooting themselves in the
foot with direct pointers to memory.
WRONG!
It's the absence of pointers that make Java safer, not the capability of
the VM to clean up your mess for you. It can't! It can't be smarter than
you no matter how hard you try!
If I was to rewrite java from scratch I would simply make that stupid
and utterly useless
Object.finalize()
method active and native instead of passive and empty!
So, instead of doing
HashMap map = new HashMap();
map.add("a","1");
map.add("b","2");
...
map = null // let's make it ready for GC
you call your stinking
map.finalize();
[much better names would be destroy(), dispose(), cleanup()]
that invalidates it and turns 'map' into a null and recursively
invalidates all those objects that are not bound to any other object
(this can be done asynchronously, but it's a VM implementation detail)
- o -
Berin points out that people might forget to dispose thier components,
thus producing leaks. If made automatic, component GC could eliminate
this problem entirely and make it easier to use Avalon.
I agree on the intention but I question the effectiveness of the
approach: Java has shown that GC doesn't eliminate memory leaks because
the program has no way to interact with the garbage generation strategy
of the JVM.
This was somewhat changed with WeakReferences: the GC treats objects and
weakobjects differently. Unfortunately, these are hardcoded GC
strategies and there is no way to create ThreadGroupObjects or other
similar GC strategy aspects.
It's evident: the java architects didn't bother much at making object
construction strategies more aspect oriented, and they did the same with
object destruction.
So, from an elegance point of view, it makes perfect sense, for Avalon,
to provide aspect-oriented construction strategies *and* aspect-oriented
destruction strategies.
Just like it's the component manager's concern to construct your
component the way the component was instructed to (depending on the
interfaces it implements), similarely, it should be the component
manager's concern (or some proxy slave, that's an implementation detail)
to dispose the component, depending on the disposing strategy that the
component implements.
- o -
The only concern I have is the fact that the dispose() method for the CM
might still be required for all those cases where the strategy might not
apply correctly, or for those cases where a strategy would need native
access to the JVM to fully obtain enough information to perform.
I think that even if we come up with a transparent component disposable
strategy framework, the dispose() method in the CM woudn't hurt and
would keep everybody happy.
--
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
component construction & destruction concern (RE: [Design]
ContainerManager is under fire--let's find the best resolution)
Posted by Leo Simons <le...@apache.org>.
up front summary: construction/destruction is not the concern of the CM,
but of the Container. The framework lifecycle interface associated with
destruction is Disposable.
> > <snip>
> >
> > So, from an elegance point of view, it makes perfect sense, for Avalon,
> > to provide aspect-oriented construction strategies *and* aspect-oriented
> > destruction strategies.
> +1000
This indeed makes perfect sense. Good analysis (including the <snip>ped
bits)!
> > Just like it's the component manager's concern to construct your
> > component the way the component was instructed to (depending on the
> > interfaces it implements), similarely, it should be the component
> > manager's concern (or some proxy slave, that's an implementation detail)
> > to dispose the component, depending on the disposing strategy that the
> > component implements.
> +1000 again
Here is where the doubts are. Is it the ComponentManagers concern to
construct / destruct your Component?
No, that's the Container. The ComponentManager is one of the
communication mechanisms between container and contained component,
aimed at providing components with references to other components.
How should a Container determine when a Component can be destructed?
What is the contract for this?
simple: when the Component has run through its lifecycle it can be
safely destructed.
Flow:
// in SomeContainer:
SomePool.start();
SomeCM.put( SomePool, SomePool.ROLE, SomePool.SOME_HINT );
// construction concern
component.compose( SomeCM );
component.initialize();
// program flow concern
component.start();
component.stop();
// destruction concern
component.dispose();
SomeCM = null; // GC's a bitch
SomePool.stop(); SomePool.dispose(); // release all
SomePool = null; // GC's a bitch
// in SomeComponent:
compose( ComponentManager cm )
{
if(cm.exists(SomePool.ROLE, SomePool.SOME_HINT)
m_pool = (Pool)ComponentManager.lookup(SomePool.ROLE,
SomePool.SOME_HINT);
}
initialize()
{
m_poolInstance = m_pool.getInstance();
}
start()
{
m_poolInstance.doStuff();
}
stop()
{
m_poolInstance.stopDoingStuff();
}
dispose()
{
m_pool.release(m_poolInstance);
}
Now for transparant pooling:
SomePerformantComponent.start();
// in SomeContainer:
SomeCM.put( SomePerformantComponent, SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT );
component.compose( SomeCM );
component.initialize();
component.start();
component.stop();
component.dispose();
SomeCM = null; // GC's a bitch
SomePerformantComponent.stop(); SomePerformantComponent.dispose();
SomePerformantComponent = null; // GC's a bitch
// in SomeComponent:
compose( ComponentManager cm )
{
if(cm.exists(SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT)
m_comp = (Pool)ComponentManager.lookup(
SomePerformantComponent.ROLE,
SomePerformantComponent.SOME_HINT);
}
initialize()
{
}
start()
{
m_comp.doStuff();
}
stop()
{
m_comp.stopDoingStuff();
}
dispose()
{
}
// in SomePerformantComponent:
/* implement pooling here */
Sure enough, the container has a tough job (especially as it might be
the one actually doing the pooling on a poolable component) , but the
result is a simple client API.
cheers,
- Leo
--
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 Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> <snip/>
>
> So, it makes perfect sense to merge the two aspects into a single CM.
+1
> <snip/>
>
> You know what? I'm starting to think that the java GC is a gigantic
> mistake. Why? simple, it's useless.
>
I totally agree here - before I started Java programming I used many
other languages where you explicitly have to care about object disposal.
If you follow one or two strict rules, you don't have any problems and
really do not need a GC - but let's focus on the topic again. Java has
a GC - and we will not change it, anyway.
> A GC continue to skeep thru your object space to look for 'detached'
> objects. That's a great implementation, but what if I forgot to 'detach'
> those objects?
>
> If GC was that effective, why Java programs leak memory anyway?
>
> Some people believe that Java is inherently safer than C because it has
> garbage collection that prevents people from shooting themselves in the
> foot with direct pointers to memory.
>
> WRONG!
>
Exactly!
> <snip>
>
> So, from an elegance point of view, it makes perfect sense, for Avalon,
> to provide aspect-oriented construction strategies *and* aspect-oriented
> destruction strategies.
+1000
>
> Just like it's the component manager's concern to construct your
> component the way the component was instructed to (depending on the
> interfaces it implements), similarely, it should be the component
> manager's concern (or some proxy slave, that's an implementation detail)
> to dispose the component, depending on the disposing strategy that the
> component implements.
+1000 again
Carsten
--
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 "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>
Re: [Design] ContainerManager is under fire--let's find the best
resolution
Posted by Stefano Mazzocchi <st...@apache.org>.
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: <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 Stefano Mazzocchi <st...@apache.org>.
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 Paulo Gaspar <pa...@krankikom.de>.
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: <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 Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> <snip/>
>
> So, it makes perfect sense to merge the two aspects into a single CM.
+1
> <snip/>
>
> You know what? I'm starting to think that the java GC is a gigantic
> mistake. Why? simple, it's useless.
>
I totally agree here - before I started Java programming I used many
other languages where you explicitly have to care about object disposal.
If you follow one or two strict rules, you don't have any problems and
really do not need a GC - but let's focus on the topic again. Java has
a GC - and we will not change it, anyway.
> A GC continue to skeep thru your object space to look for 'detached'
> objects. That's a great implementation, but what if I forgot to 'detach'
> those objects?
>
> If GC was that effective, why Java programs leak memory anyway?
>
> Some people believe that Java is inherently safer than C because it has
> garbage collection that prevents people from shooting themselves in the
> foot with direct pointers to memory.
>
> WRONG!
>
Exactly!
> <snip>
>
> So, from an elegance point of view, it makes perfect sense, for Avalon,
> to provide aspect-oriented construction strategies *and* aspect-oriented
> destruction strategies.
+1000
>
> Just like it's the component manager's concern to construct your
> component the way the component was instructed to (depending on the
> interfaces it implements), similarely, it should be the component
> manager's concern (or some proxy slave, that's an implementation detail)
> to dispose the component, depending on the disposing strategy that the
> component implements.
+1000 again
Carsten
---------------------------------------------------------------------
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 Paulo Gaspar <pa...@krankikom.de>.
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