cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Separation of Blocks and Avalon
Date Tue, 14 Oct 2003 13:17:14 GMT
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.
> Me, too. And I'm really wondering if we can keep our nice little additions
> if we move away from ECM.

You may be able to, but they will be done differently.  For instance, Merlin
and Fortress use the Lifecycle Extensions API which can be used for most of
the special things you are doing.

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

You might be able to get around this with a PerThread model, as I am
not aware of any Java Servlet container that shares the same thread
between multiple requests.

We will have to look at what options are available to implement this.

> 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 more and more thinking that we should do one thing after the other:
> first creating our blocks and than moving to fortress or merlin.
> 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).

ECM is ok when you already have an infrastructure built with it.  However,
maintaining the roles file and the component source code can let things
get out of sync--esp. if you are refactoring.  Fortress and Merlin will
allow you to change EVERYTHING about the implementated component--including
the package it resides in--without requiring changes anywhere else.  Try
that with ECM.

It opens up the doors to refactoring a bit wider.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message