cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] New processor interface/approach
Date Wed, 12 Jul 2006 14:50:28 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Are you using so many sitemap processors so that becomes a problem? We 
>> have something like that today. The tree processor is configured as a 
>> component, or will a Spring bean configuration be much more verbose?
> No, the spring bean config might look the same (more or less). Perhaps
> we could even use spring templates to simplify (don't know yet, I have
> to look into that).
> Anyway, my idea is to not use mount (= sub sitemaps) anymore. So I guess
> I will end up with several sitemap processors. I think we should remove
> the concept of sub sitemaps completly (this would make our code much
> more cleaner) as you never really know which sitemap processes what. And
> with this new processor concept we don't need it anymore.
OK, that explain your concern and the need for the MountTableProcessor. 
I agree about getting rid of the mounts. They have mainly been used for 
modularization, and with the current development we get better 
mechanisms for that. Now, it is not the mounts in them self that create 
complexity, it is mounts combined with component declarations in 
(sub)sitemaps that complicates things.

>> Irrespectively of if the bean configuration becomes verbose or not, it 
>> will help us towards better modularization. Each block, or rather each 
>> sample block, can contribute its sitemap as a sitemap processor that is 
>> configured in its bean configuration. In this way we get rid of the 
>> sitemap copying part of the deployer.
> Yes, definitly true. So let's try this way.

Here I also would like to advertise a neat pattern (the whiteboard 
pattern) that we use in the OSGi-blocks architecture, that we maybe 
could use without OSGi in 2.2.

So, in the block architecture we set up a BlockServlet (or other 
controllers) as a managed component by using the declarative services, 
this could be done in Spring instead. Anyway, the configuration contains 
a default mount path that can be overridden by the configuration 
service. Then the component that corresponds to the MountTableProcessor 
can ask the service manager for all services that implements Servlet and 
that also has a mount path property. And it can mount these servlets 
without any global configurations at all. It also allows for dynamic 
installation/uninstallation/update of the servlets, but that is another 
story ;)

Maybe we could use the same pattern with Spring managed processors. Is 
there any way to ask the container for all beans that implements a 
certain interface? It would make it possible to just deploy a block 
without needing to update any mount tables.


View raw message