cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [2.2] Runtime deployment
Date Sat, 04 Nov 2006 12:54:16 GMT
Leszek Gawron wrote:
> Giacomo Pati wrote:
>> Class org.apache.cocoon.maven.deployer.monolithic.DevelopmentBlock has
>> no such attribute: sitemapAdditionsConfPath in template context
>> [anonymous anonymous]
>> java.lang.NoSuchFieldException: sitemapAdditionsConfPath
>>         at java.lang.Class.getField(
>>         at
>> org.antlr.stringtemplate.language.ASTExpr.getObjectProperty( 
>> ...
>>         at
>> org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.writeStringTemplateToFile(

>> I havn't see the remove of the isSitemapAdditionsConfPath method from
>> the DevelopmentBlock class. If I remove the
>> $if(devblock.sitemapAdditionsConfPath)$
>>   <include dir="$devblock.sitemapAdditionsConfPath$" pattern="*.xmap"/>
>> $endif$
>> part from the
>> tools/cocoon-block-deployer/cocoon-deployer-plugin/src/main/resources/org/apache/cocoon/maven/deployer/monolithic/WEB-INF/cocoon/cocoon.xconf

>> (dunno whether this is still needed but I guess not anymore).
> you're right - this is not needed. I have removed the entry but the 
> deployer still needs fixing - I see it tries to load the config files 
> the old way from src/main/resources/META-INF/cocoon:

There is a major flaw in locally testing a development block: 
classloading. Deploying a dvelopment block is different from standard 
procedure. None of the resources are copied to webapp directory. They 
are referenced from source.

We are reading now spring/properties configuration directly from 
classpath. The problem is that block's classpath resources are being 
mounted with reloading class loader using target/classes folder.

The mount is being created at block's sitemap level. This is what causes 
the problem:

- core will not pick up spring/properties/avalon files now
- even if we mount the files directly from source it will not do much 
good because core will not be able to find classes for beans defined in 

The only scenario that works now is when the devlelopment block has some 
COB-INF resources and does not contribute any classes to core. In other 
words any spring/avalon context is contributed at 
COB-INF/config/{spring|avalon} level)

This is not the fault of latest changes (it just made some problems more 

We somehow have to make cocoon see development block classes at root 
classloader level. Any clues?

Leszek Gawron                                    CTO at MobileBox Ltd.

View raw message