cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Configuring BlockServlets via properties and sitemap reloading for blocks
Date Mon, 16 Oct 2006 18:37:32 GMT
Alexander Klimetschek skrev:
> Hi Daniel,
> I am playing around with the new blocks protocol and the BlockServlets.
> I have two blocks A and B, B "inherits" from A and then there is a 
> webapp that uses both blocks. The webapp has the DispatcherServlet 
> configured in the web.xml and the mountPath for the two blocks is 
> defined in the spring-bean config XML file. Now I face two problems:
> 1) I'd like to configure the mountPath to the blocks in the webapp, 
> because the blocks itself are generic; I have tried it with a 
> properties file manually placed in WEB-INF/cocoon/properties that sets 
> the mountPath:
> com.domain.package.blockA.mountPath=foo
> But this does not work. How can I override the setting in the bean 
> config XML with a property?
The possibility to override bean properties is very new and I have not 
tested it yet, see for a 
description of how it is supposed to work. I am not certain that it is 
tested yet. Maybe Carsten can say something about it.

For the moment it might be a safer bet to use the property mechanism 
that already is part of trunk. Here you need to use parameters like  
${com.domain.package.blockA.mountPath} directly in the configuration and 
give them a default value in a property file. See e.g.

> 2) The nice development feature of sitemap reloading does not work 
> when working on blocks, because you cannot deploy a block with it's 
> own web.xml (that has the necessary DispatcherServlet). I use the 
> webapp which will use the packaged jars from A and B.
> The hurdles here are:
> a) the cocoon deployer will overwrite the web.xml with no 
> DispatcherServlet configured
In the short term we should fix the deployer so that it doesn't remove 
the DispatcherServlet. I don't know much about how the deployer works, 
could someone who does comment on this?

We have some ideas about how to get rid of the need for the deployer in 
the development cycle. See, and for 
that discussion.

> b) the blockContextURL should point to the source-folder (like in the 
> sitemap generated by the deployer) so that reloading works on the 
> developer's working directory
Currently the implementation only resolves a path relative to the webapp 
context (like for the context: protocol). This should clearly be 
generalized to be able to handle other protocols.

> c) that blockContextURL must be overwritten by the deployer via a 
> property (problem like in 1)
See my answer to 1)

> I'd imagine a deployer that recognizes the 
> -Dorg.apache.cocoon.mode=dev and then configures the webapp to work as 
> above. I could do some work on the deployer plugin if those points are 
> resolved.
Patches are always welcome.

> Another question then arises for the final wiring of blocks: typically 
> I have a root sitemap and mount my different sub-sitemaps there. But 
> when each sub-sitemap is now served via a BlockServlet I must have the 
> DispatcherServlet listening on "/" so that I need a separate 
> BlockServlet serving the root (like /index.html). It would be very 
> cool if one could mount a BlockServlet directly inside the root sitemap.
I think there are two main scenarios: You use a ordinary PipelineServlet 
for the root sitemap and BlockServlets for the blocks that you use. Or 
you let everything including the root sitemap be a block.

To make it easy to start using blocks from existing Cocoon webapps we 
should probably make the first alternative easy to use. In that scenario 
you typically will mount a SitemapServlet containing the root sitemap at 
"/", and the DispatcherServlet at e.g. "/blocks". The block protocol 
doesn't work from the root sitemap to the blocks, as the block protocol 
is designed for inter block communication and require that blocks are 
wired together with Spring. It might work with 
"http:/blocks/myBlock/foo", not certain though. I'm thinking about 
implementing a "blocks:" protocol for this scenario. It would use the 
global bean id for the block instead of the bean local property name. 
There was something like that in an early incarnation of the blocks 

For the case when also the main sitemap is in a block, you can just wire 
it to the used blocks and use the block: protocol. As long as the block 
deployer is required for updating the block, this would be rather 
painful. We really need to do something about the deployment.

Thanks for testing the blocks framework and for the feedback.


View raw message