Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <456B6DEA.6070505@nada.kth.se>
Date: Mon, 27 Nov 2006 23:59:54 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Trying to start Cocoon 2.2
References: <ekcvm5$56d$1@sea.gmane.org>
 <b72585879cec66b9c488961e8008b9a4@wrinkledog.com>
 <ekd5d1$kcc$1@sea.gmane.org>
 <2a6807812ab21b995164214b91671bac@wrinkledog.com>
 <456A86E2.8030505@pobox.com> <ekfij7$sta$1@sea.gmane.org>
 <456B5B74.5090405@nada.kth.se> <ekfnpl$i1u$1@sea.gmane.org>
In-Reply-To: <ekfnpl$i1u$1@sea.gmane.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Luca Morandini skrev:
> Daniel Fagerstrom wrote:
>> Luca Morandini skrev:
>>> Patrick Refondini wrote:
>>>>
>>>> shouldn't it be :
>>>> -Dmaven.war.shieldingclassloader=false
>>>
>>> Thanks for this bit of information, but Cocoon doesn't run yet.
>>>
>>> I did:
>>> mvn -Dmaven.test.skip=true -Dmaven.war.shieldingclassloader=false 
>>> clean install
>>> cd core/cocoon-webapp
>>> mvn jetty:run-exploded -Dorg.apache.cocoon.mode=dev
>>
>> I have had problems lately with that an avalon-framework-4.0.jar (from 
>> 2002!) is included in target/cocoon-webapp/WEB-INF/lib. It shadows the 
>> Avalon framework 4.3 jars that Cocoon depends on and give a stack 
>> trace similar to yours. Remove the faulty jar and try to run Cocoon 
>> again.
> 
> I don't think this is the issue, since I see only two Avalon JARs, both 
> 4.3 (avalon-framework-api-4.3.jar, avalon-framework-impl-4.3.jar).

Yes, I found out (by building with -X) that it is the batik block that 
include the faulty avalon jar. And I had added the batik block my self 
for testing purposes.

>> Some other points: jetty:run-exploded seem to do some unnecessary 
>> extra work compared to jetty:run. Use the -e switch for jetty:run so 
>> that you get the whole stack trace. Otherwise it is very hard to see 
>> what is the problem.
> 
> Here you are, Sir:

Great ;)

> [INFO] [jetty:run]
...
> file:/C:/apps/cocoon-2.2-dev/core/cocoon-webapp/target/cocoon-webapp/WEB-INF/lib/cocoon-deployer-plugin-classloading.jar, 

This is strange, I don't have this jar on my class path. It is probably 
a leftover from a build without the 
-Dmaven.war.shieldingclassloader=false switch. Try a "mvn 
-Dmaven.war.shieldingclassloader=false clean install" in the cocoon-webapp.

Actually a "mvn war:exploded" is even better as it is much faster 
(doesn't build the war file), and doesn't call the deployer.

...
> Caused by: java.lang.RuntimeException: Cannot invoke listener 
> org.springframework.web.context.ContextLoaderListener@22e177
>         at 
> org.apache.cocoon.maven.deployer.servlet.ShieldingListener.invoke(ShieldingListener.java:181) 
> 
>         at 
> org.apache.cocoon.maven.deployer.servlet.ShieldingListener.contextInitialized(ShieldingListener.java:204) 
> 
>         at 
> org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:441) 

And here we can see that shielding classloader seem to be called anyway. 
Probably the web.xml is patched to use the shielding stuff after an 
earlier build.

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).

/Daniel