cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Dependency on WebApplicationContext
Date Sat, 25 Feb 2006 20:40:02 GMT
Daniel Fagerstrom wrote:
> The users are not the only stakeholders the developers are at least as 
> important, especially in an open source community. One of the recurring 
>    themes in all the NG discussions is that people are deeply frustrated 
> with not being able to try their new ideas because of the complexity of 
> Cocoon. This must be solved by simplify Cocoon and by making the 
> contracts between different parts clearer.
I totally agree here.

> IMO the direct dependence of
> the XmlWebApplicationContext is a step in the opposite direction.
Not necessarily - XmlWebApplicationContext has a hugh interface, but in
fact this one is easy and everyone who knows spring knows this one
anyway. But if we can get this one out of the tree processor, I'm all
for it.

> Most of the code in the ecm block service manager 

> is about setting up a block local source resolver, which not is as easy 
> as one  might assume.
> That particular mechanism for having a block local service manager that 
> makes components available for other blocks was mainly designed for ecm. 
> So we can do it in some other way for a Spring block service manager.
> Any ideas about how to proceed?
Hmm, I see that ECMBlockServiceManager has several problems; for example
it creates a Core and a settings object which it definitly should not as
there should only be one Core object and settings object for the whole
Cocoon installation.
Now, I see that the current ECMBlockServiceManager implements the usual
Avalon stuff; can we assume that the service manager which is feed into
the service() method is either the root service manager or a child of
it? In that case, that one already contains the Core object etc.
But in the end, we have the same problem here as the tree processor has:
we need to setup a Spring application context which should have a parent
Spring application context. Setting up this context is easy, the problem
is getting the parent context. And this is imho exactly the point where
we depend on the container implementation. The current block
implementation uses the Avalon interfaces which we could for example
replace with the Spring application context (no dependency to Avalon
Agreed, the Spring application context interface is bigger than the
simple ServiceManager interface, but again - it's well known - and it
provides more useful functionality. If we don't want this dependency
then I fear we have to create our own "container" interface as
ServiceManager is definitly not enough. For example, we need a way to
get the parent container and we need a way to shutdown the container and
it's childs etc. But we would again create interfaces noone knows
upfront, increasing the learning curve.
So I suggest, let us base all the component stuff on Spring, use the
Spring application context (or more precisley the CocoonXml...) and
continue from there.

This would mean, first seeing how this block registry could look like
and from there implement the spring blocks impl which should be really

Carsten Ziegeler - Open Source Group, S&N AG

View raw message