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(Class.java:1507)
at
org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:328)
...
at
org.apache.cocoon.maven.deployer.monolithic.MonolithicCocoonDeployer.writeStringTemplateToFile(MonolithicCocoonDeployer.java:216)
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
block/META-INF/cocoon/spring/*.xml
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
visible).
We somehow have to make cocoon see development block classes at root
classloader level. Any clues?
--
Leszek Gawron CTO at MobileBox Ltd.
