cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Morandini <>
Subject Re: Trying to start Cocoon 2.2
Date Tue, 28 Nov 2006 17:06:26 GMT
Daniel Fagerstrom wrote:
> Luca Morandini skrev:
>> Embedded error: Error creating bean with name 
>> 'org.apache.cocoon.core.main.block' defined in URL 
>> [jar:file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-core-main-sample-1.0.0-SNAPSHOT.jar!/META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml]:

>> Invocation of init method failed; nested exception is 
>> org.springframework.beans.factory.BeanCreationException: Could not 
>> create configuration for TreeProcesoor; nested exception is 
>> Couldn't find the sitemap /sitemap.xmap
>> [INFO] 
>> ------------------------------------------------------------------------
> There is still something strange in your setup. As you can see above, 
> Cocoon (in o.a.c.core.deployment.DeploymentUtil I would assume) reads 
> from the jar: cocoon-core-main-sample-1.0.0-SNAPSHOT.jar, which not 
> should be on the dependency list from recent cocoon-webapp checkouts. 
> Probably there is an old version of the jar in your 
> cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/ directory.

I zapped the contents of cocoon-webapp/target and rebuilt: no joy.

> We have updated the deployment mechanism recently, and I got the same 
> error message a short period before I updated the bean configuration in 
> META-INF/cocoon/spring/cocoon-core-main-sample-blockServlet.xml for 
> cocoon-core-main-sample. To work the value of the property 
> blockContextURL in the configuration file should be 
> blockcontext:/cocoon-core-main-sample/ instead of a relative URL as it 
> was before. So you probably either get an old version of the 
> cocoon-core-main-sample or an old version of cocoon-core.

Well, actually 
has the correct value of blockContextURL (I did an svn update, so this 
doesn't come as a surprise to me).

> ...
>>> The next question is of course why the shielding classloader doesn't 
>>> work in some environments. It works for me (jdk1.5.0_06, Windows XP).
>> It's the same environment for me as well.
> Then something else must differ. I don't know that much about the 
> working of the shielding classloader. Maybe Carsten has some hypothesis.

How can I be sure to have your exact configuration: dropping the maven 
repo and build everything from scratch (how painful !) ?


    Luca Morandini

View raw message