cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Dependency on WebApplicationContext
Date Sat, 25 Feb 2006 20:17:45 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> I'm completely against having the treeprocessor hardwired to that freak 
>> class. The treeprocessor should depend on a (small) interface that 
>> describe what it actually need from its container.
> Yeah, sure. The tree processor has a long history and as we changed the
> underlying container now twice the code got not better from that :( I'm
> +1 for cleaning up the tree processor. But imho it's a little bit
> difficut to make it independent from the container as we have a
> hierarchy of sitemaps, creating a hierarchy of containers. So the tree
> processor needs a way to setup a container a get the parent container
> for that. Or maybe the code could be moved out of the tree processor to
> separate this.
> But on the other hand, the tree processor is working. So, is there a
> real problem (apart from being ugly) with it? If you want to use the
> tree processor, just look it up from the component manager and use it.
> It's transparent to users how it does things inside.

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. IMO the direct dependence of 
the XmlWebApplicationContext is a step in the opposite direction.

>> Right now it feels like there are hours an hours of work before I get 
>> back to have a working block implementation again.
> I'm sorry for that. Of course this was not my intention. Where exactly
> are your problems? For me at least everything compiles.

My testcases:,

doesn't work anymore. The blocks samples,

doesn't work anymore. Reinhard's work on block deployment, 
doesn't work anymore.

> Again, what is not working? As you and others have said in recent
> threads, the core is working again; there was a problem with the default
> handling of sitemap components which should be fixed now. I guess there
> are more of these minor issues which we can fix easily as soon as they
> turn up. I'm sorry that my work made your work harder, but I wasn't
> aware of any such thing; the only piece of code I'm sure I broke is the
> ecm block implementation,

Yes, that is what broke, and the blocks depend on it. Now it need to be 
replaced with a new implementation that embeds the Spring bridge, as the 
treeprocessor internals depends on that the parent manager respects 

> which I simply do not understand to get it
> fixed but I'm here to help getting that work again.

The main idea is that each block manage its own sets of components, that 
it make available to the other blocks.

In the ECM block manager that is solved by the use of a global service 
manager registry,

the service manager within a specific block register each component id 
(role) together with a reference to it self in the service manager 
registry. The service manager registry is also a service manager that is 
used as parent manager to all the blocks service managers, and it is 
used for getting components that are managed from other blocks.

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?

> But on the other hand I did you a favour and now the Context object
> extends the ServletContext :)



View raw message