cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Using Spring instead of ECM++
Date Mon, 13 Feb 2006 22:42:33 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> It depends on how long time you think that it will take. If you think 
>> that it take a week or so I suggest that you branch cocoon-core, and 
>> work on the branch until it works again and merge it back then. In the 
>> meantime the rest of us try to avoid doing larger changes in cocoon-core 
>> trunk.
>> If it takes like a month or so, it is better to try to do some splitting 
>> of cocoon-core first, so that you only need to branch the tree-processor 
>> and the top layer that contain the Cocoon object.
> Ok, I think this will take one or two days until Cocoon runs again while
> it might take a little bit longer to polish everything.

A branch of cocoon-core then.

>> In any case it must be done in a branch. We are making good progress 
>> with the blocks work, and having a cocoon-core that doesn't would be a 
>> far to large disruption.
> I'm wondering if I'm changing the right place. Now the switch to Spring
> is finished cocoon-core will look different (less use of Avalon). Now,
> has this any influence on the blocks implementation like block-fw?

Probably ;)

Take a look at the BlockManager. It first set up a container which for 
the moment is hardwired to o.a.c.container.ECMBlockServiceManager, but 
could be another container. The container is supposed to register the 
components that it want to make available to other block in a 
ServiceManagerRegistry, and it get components from other container 
through it parent manager (also the ServiceManagerRegsitry).

Then a block servlet (typically o.a.c.sitemap.SitemapServlet that 
contains the tree processor) is set up and is given the component 
manager of the block.

The contract for the Container is probably not the best possible, but I 
needed something to be able to continue. Comments are welcome.

> I looked there briefly and saw that for example ServiceManager is used
> there for getting components from a block. We should change that as well
> and perhaps use our own interface?

Maybe, it was first idea as well. But the ServiceManager is a rather 
generic interface, so I don't see that we would find something 
different, so I don't see what it would by us to change.

And in the somewhat longer perspective I would prefer using the OSGi 
interfaces for service management.

> And if the cocoon-core uses Spring what has to be done in the blocks-fw?

I don't know how you are planning to integrate Spring, so it is hard to 

If we think about it, the main reason for having a component manager 
within the sitemap and even in subsitemaps, is that 1) 
sitemap-components  and ordinary components was supposed to be different 
concern in early Cocoon designs, and 2) that subsitemaps has been the 
major mechanism for modularizing large applications.

We don't care about the difference between sitemap-components and 
ordinary components anymore and with blocks there is a better 
modularization mechanism than subsitemaps. So question is why we should 
configure components within sitemaps anymore. IMO it is a mix of concern 
and makes the tree-processor unnecessarily complicated.

So I don't know if the tree-processor should use Spring (or any other 
component manager) anymore, it would be enough to just feed it a service 

The Cocoon object and the CocoonServlet are not used anymore in the 
blocks fw. I tried to adapt to them early on but it required to much 
work to integrate the blocks within them without risking to disturb the 
rest of the system. Besides that, the setup sequence tended to give me 
severe headache, so I rewrote it to something less flexible and less 


View raw message