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 Tue, 17 Oct 2006 17:34:59 GMT
Alexander Klimetschek skrev:
> Hi,
> thanks for your answer! Things are really getting better now, as I got 
> reloading to work ( 
> as written in the other mail.
Great. The patch looks good, I will apply it.

> Daniel Fagerstrom schrieb:
>>> 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.
> I got it working when I placed the properties file in my webapp-module 
> under WEB-INF/cocoon/spring and naming the property
> <bean-id>/<param>=<value>
> so for example:
> com.domain.package.blockA/mountPath=/foo

>> We have some ideas about how to get rid of the need for the deployer 
>> in the development cycle. See 
>> and 
>> for that discussion.
> That would indeed be very nice. But how does the reloading work then? 
> Deploy a special jar into cocoon/libs that somehow points to its 
> original source folders?
No, we discussed having a configuration file with associations between 
block name and block path, that overrides the blocks in the classpath. 
By using that you can point to your block under development.

>>> 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.
> Will see if I modify the deployer for that case. My manual solution 
> (see the JIRA issue) works so far, so this might happen later. Maybe 
> someone has changed the way of deploying by then ;-)

>> 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 framework.
> Does this mean I could mount a BlockServlet inside a sitemap via 
> map:mount src="blocks:<global-bean-id>"?

> That sounds very cool and should IMHO be part of the blocks-framework 
> before releasing 2.2.

>> 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.
> Reloading does work now with my patch, so I'll try that! No more 
> SitemapServlet inside the web.xml configuration ;-)
>> Thanks for testing the blocks framework and for the feedback.
> Well, I really like the inheriting feature because it allows you to 
> extract general stuff out of your sitemap into an "abstract" super 
> block. And we got a case where we need that. If you put together 
> components in Cocoon and actually program in sitemaps, you have to be 
> able to separate stuff and let sitemaps itself stand as new components 
> - which is what blocks now provide.
We have built reusable applications on my company, using a much more 
primitive mechanism for sitemap inheritance, and it works very well. 
That has been the main motivation for me to work on the blocks framework.


View raw message