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
answer.
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
manager.
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
complicated.
/Daniel
