cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject RE: [RT] Separation of Blocks and Avalon
Date Fri, 10 Oct 2003 14:01:08 GMT
On Fri, 10 Oct 2003, Carsten Ziegeler wrote:

> Stephen McConnell wrote:
> >
> > The million little details that cocoon assumes on top of ECM is also the
> > thing that scares me the most.

Absolutely right! IMHO we've ridden our own train for too long and am
now in the situation where we are far from what Avalon can supply to
Cocoon in the Container arena.

> >
> Me, too. And I'm really wondering if we can keep our nice little additions
> if we move away from ECM.

See below.

> > Is there someone who provide the breakdown of what Cocoon is doing over
> > and above ECM?  However things roll out - one of the biggest obsticles I
> > see is that we need to move away from ECM/Fortress extension and to a
> > solution where Cocoon does not need to access container APIs.  With that
> > information the Avalon crowd can address how to addres these
> > requirements in a way that makes the concern indpendent of the container
> > implementaiton.
> >
> We extend the ECM with our CocoonComponentManager, you can have a look
> at that class. All the features (hacks?) in there have to be somehow
> available using fortress, merlin or whatever.
> We have another lifecycle type, the request lifecycle component. This is
> an extension to poolable and means that per request only one instance
> of this component is used. So if two other components lookup this
> request lifecycle component, they get the same instance.
> The implementation of this extension is a little bit difficult as we
> have sub requests that run in the same thread but have a different
> set of request lifecycle components.
> In addition it's possible to process on request multi threaded which
> makes this even more difficult.

IIRC Fortress can handle this with a special Handler we have to supply
(instead of subclassing the hole Container class). Remeber that in
Fortress Object handling is separated into meta data instead of
additional marker interfaces. There is no Poolable, ThreadSafe, etc. any
more but ThreadSafeComponentHandler, PoolableComponentHandler instead.

> There are some other important extensions like the environment handling
> for the source resolver and the sitemap configurable components. They
> use more or less the same technique used for the request lifecycle
> components.

I'm sure there is a way for this also and with the help of a Handler it
can be made with IOC in mind.

> I'm more and more thinking that we should do one thing after the other:
> first creating our blocks and than moving to fortress or merlin.

My hope was that the hole Classloader stuff could be delegated to one of
the new Containers.

> Or the other way round, if someone things that it makes more sense.
> But we should avoid doing both at the same time.
> I mean, we are currently happy with ECM - it works, it's stable and the
> only real concern we have is the big cocoon.xconf which is solved with
> blocks anyway. (I don't want to say that fortress/merlin are not stable
> with this).

Yes, but the world is still spinning and there are alot of other
Component out there that don't follow the ECM style because it's
deprecaded for long time now and every time we want to use such a
component we have to extend the working interface to make it a
'Component' for ECM and extend the implementation to have our interface
implemented (do you remember the Cornerstone Scheduler?).  That's ugly!

As a side note: I got the impression (and that supprises me alot) there
is too little knowledge around here what Avalon is doing and where it is
moving in the so central Component Container discipline. This IMHO led
to this 'we think Avalon cannot supply what we want' situation and so we
are ignoring the helping hand Avalon people put forth several times now.

Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -

View raw message