You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by is...@cocoondev.org on 2004/04/20 15:38:03 UTC
[issues] Created: (FOR-133) Cocoon.xconf is misconfigured in WAR
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.cocoondev.org/jira//secure/ViewIssue.jspa?key=FOR-133
Here is an overview of the issue:
---------------------------------------------------------------------
Key: FOR-133
Summary: Cocoon.xconf is misconfigured in WAR
Type: Bug
Status: Unassigned
Priority: Critical
Project: Forrest
Component: Building Forrest
Versions:
HEAD
Assignee:
Reporter: Sjur N. Moshagen
Created: Tue, 20 Apr 2004 3:36 PM
Updated: Tue, 20 Apr 2004 3:36 PM
Environment: MacOS X 10.2.8, latest forrest
Description:
When building a war file, the generated WEB-INF/cocoon.xconf file contains absolute paths to the resources, content, catalogs etc of the webapp as found on the development computer. This brakes the war when installed in a servlet container. Manually editing cocoon.xconf after installing the war fixes the issue.
[While I wrote this bug report, nicolaken wrote an UPDATE about what looks like the same issue. But since I could not find a bug report covering it, I found it better to file the report as not to forget to test against it later on.]
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org/jira//Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in
WAR
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sjur Nørstebø Moshagen wrote:
...
>> You are right the need for cocoon-live.xconf should be removed by
>> this work. But I don't know if Nikola Ken has tested this, I don't
>> think this is one of his use cases. Perhaps you could test it for us?
>
> I would be happy to, anytime (almost;)
I'll give the list a heads up when it's ready for testing. TIA :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in WAR
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
På 23. apr. 2004 kl. 00.08 skrev Ross Gardler:
>> The crash is pretty bad, so others should be warned at least. Other
>> than that - I'm not sure there's any point in fixing the bug if
>> there's another solution coming soon.
>
> Yes, and I see another load of commits from Nicola Ken so if you can
> wait so can I.
We'll wait, then.
> By then I should be able to put some more time in here, so if can do
> some thorough testing between us.
Fine.
Sjur
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in
WAR
Posted by Ross Gardler <rg...@apache.org>.
Sjur Nørstebø Moshagen wrote:
>
> Round 1 - with original, broken cocoon.xconf file:
As expected as you say.
> Round 2 - including the block that copies cocoon-live.xconf to the webapp:
>
> - uncommented the cocoon-live.xconf block in my local svn copy of the
<snip/>
>
> FAIL - Application at context path /my-project could not be started
> java.lang.IllegalStateException: standardHost.start /my-project:
> LifecycleException: Container StandardContext[/my-project] has already
> been started
<snip/>
> The crash is pretty bad, so others should be warned at least. Other
> than that - I'm not sure there's any point in fixing the bug if there's
> another solution coming soon.
Yes, and I see another load of commits from Nicola Ken so if you can
wait so can I. We are in the minority using live WAR files so I doubt
other members of the community care too much right now.
> So, I am not urgently needing this to work, but as 0.5.1 does fullfill
> my immediate requirements, I'll wait until Nicola Ken's work is more
> complete.
By then I should be able to put some more time in here, so if can do
some thorough testing between us.
Ross
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in WAR
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
På 21. apr. 2004 kl. 21.17 skrev Ross Gardler:
>> root cause
>> java.lang.StackOverflowError
>> [an endless list similar to the above]
>> --------- end of error msg ---------
>
> Hmmm....
>
> You didn't get this error before temporarliy editing the ANT file. Try
> deleting the build directory and rebuilding to see if it works OK.
> This should be done in the build anyway, but lets just check that out.
>
> Also try doing forrest run - does everything work OK then?
OK, here's step by step a new round of testing:
Container: Apache Tomcat/4.1.24-LE-jdk14 (the standard MacOS X install)
OS: MacOS X 10.3.3
Java: 1.4.2 (latest available)
Round 1 - with original, broken cocoon.xconf file:
- commented out the cocoon-live.xconf block in my local svn copy of the
Forrest src;
the sources should now be identical to revision 10146 of the HEAD
trunk
- rebuilt Forrest
- installed the newly built Forrest on the test machine
- seeded a new Forrest site
- built the test site ('forrest') - succeeded
- then 'forrest run' - http://localhost:8888/ runs fine
- built 'forrest war' - successfull
- deployed the war on another machine: should work, but without finding
the files. Result:
Internal Server Error
----------------------
Message: null
Description: No details available.
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
Request URI
index.html
cause
/Volumes/Data/Users/sjur/test/src/documentation/content/xdocs/tabs.xml
(No such file or directory)
request-uri
/my-project/index.html
----------------------
Apache Cocoon 2.1.4
That is, as expected.
Editing the cocoon.xconf file in the deployed webapp fixes the above
error.
(a small naming inconsistency: <skins-dir> is named differently in the
webapp ('skin') than in the source dir ('skins'))
Round 2 - including the block that copies cocoon-live.xconf to the
webapp:
- uncommented the cocoon-live.xconf block in my local svn copy of the
Forrest src:
Changed:
<!--copy tofile="${project.webapp}/WEB-INF/cocoon.xconf"
filtering="true"
overwrite="true"
file="${forrest.home}/context/WEB-INF/cocoon-live.xconf" -->
To:
<copy tofile="${project.webapp}/WEB-INF/cocoon.xconf"
filtering="true"
overwrite="true"
file="${forrest.home}/context/WEB-INF/cocoon-live.xconf"/>
- rebuilt Forrest
- installed the newly built Forrest on the test machine
- seeded a new Forrest site
- built the test site ('forrest') - succeeded
- then 'forrest run' - http://localhost:8888/ runs fine
- built 'forrest war' - successfull
- deployed the war on another machine (through the Tomcat web-based
Manager interface) - result:
- it takes ages to deploy, and when it finally is deployed, its status
is 'stopped'
- clicking on 'start' returns an error:
FAIL - Application at context path /my-project could not be started
java.lang.IllegalStateException: standardHost.start /my-project:
LifecycleException: Container StandardContext[/my-project] has already
been started
- the status shows the app as running, and thus available
- clicking the link to the app (localhost:9006/my-project) crashes the
container!
I can find NO trace of what caused the crash in any of the likely
log files.
- upon restarting Tomcat, I get the following messages in the log
related to the my-project webapp:
2004-04-22 11:56:55 HostConfig[localhost]: Expanding web application
archive my-project.war
2004-04-22 11:56:55 StandardHost[localhost]: Installing web application
at context path /my-project from URL
file:/Library/Tomcat/webapps/my-project
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploying class
repositories to work directory
/Library/Tomcat/work/Standalone/localhost/my-project
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy class files
/WEB-INF/classes to /Library/Tomcat/webapps/my-project/WEB-INF/classes
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/avalon-framework-4.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/avalon-framework
-4.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/batik-all-1.5.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/batik-all-1.5.1.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/castor-0.9.5-xml.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/castor-0.9.5-xml.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/chaperon-20040205.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/chaperon-20040205.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-asciiart-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-asciiart-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-batik-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-batik-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-chaperon-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-chaperon-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-deprecated-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-deprecated
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-fop-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-fop-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-html-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-html-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-linkrewriter-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-linkrewriter-
block-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-lucene-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-lucene-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/cocoon-profiler-block-2.1.4.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/cocoon-profiler-block
-2.1.4.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/commons-cli-1.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/commons-cli-1.0.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/commons-collections-3.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/commons-collections
-3.0.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/commons-jxpath-20030909.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/commons-jxpath
-20030909.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/commons-lang-2.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/commons-lang-2.0.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-component-20040122.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-component
-20040122.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-event-api-1.0.4-dev.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-event-api
-1.0.4-dev.jar
2004-04-22 11:56:56 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-event-impl-1.0.4-dev.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-event-impl
-1.0.4-dev.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-i18n-1.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-i18n-1.1.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-instrument-1.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-instrument
-1.0.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-instrument-manager-1.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-instrument-
manager-1.0.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-instrument-manager-interfaces-1.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-instrument-
manager-interfaces-1.0.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-io-1.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-io-1.1.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-logger-1.0.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-logger
-1.0.1.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-monitor-1.0.2.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-monitor
-1.0.2.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-naming-1.0.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-naming-1.0.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-pool-1.2.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-pool-1.2.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-sourceresolve-1.0.2-dev.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-sourceresolve
-1.0.2-dev.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-store-1.0-dev-20040206.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-store-1.0-dev
-20040206.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/excalibur-xmlutil-1.0-dev.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/excalibur-xmlutil-1.0-
dev.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/fop-0.20.5.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/fop-0.20.5.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/jakarta-regexp-1.3.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/jakarta-regexp-1.3.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/jing-20030619.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/jing-20030619.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/jisp-2.5.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/jisp-2.5.1.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/jtidy-04aug2000r7-dev.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/jtidy-04aug2000r7-
dev.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/logkit-1.2.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/logkit-1.2.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/lucene-1.3-final.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/lucene-1.3-final.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/nekodtd-0.1.9.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/nekodtd-0.1.9.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/nekopull-0.2.3.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/nekopull-0.2.3.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/util.concurrent-1.3.2.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/util.concurrent
-1.3.2.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xalan-2.5.2.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xalan-2.5.2.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xerces-xniWriter.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xerces-xniWriter.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xercesImpl-2.6.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xercesImpl-2.6.1.jar
2004-04-22 11:56:57 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xml-apis.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xml-apis.jar
2004-04-22 11:56:58 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xml-commons-resolver-1.1.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xml-commons-resolver
-1.1.jar
2004-04-22 11:56:58 WebappLoader[/my-project]: Deploy JAR
/WEB-INF/lib/xml-forrest.jar to
/Library/Tomcat/webapps/my-project/WEB-INF/lib/xml-forrest.jar
2004-04-22 11:57:08 StandardManager[/my-project]: Seeding random number
generator class java.security.SecureRandom
2004-04-22 11:57:08 StandardManager[/my-project]: Seeding of random
number generator has been completed
2004-04-22 11:57:08 StandardWrapper[/my-project:default]: Loading
container servlet default
2004-04-22 11:59:18 StandardContext[/my-project]: Servlet /my-project
threw load() exception
javax.servlet.ServletException: Servlet.init() for servlet Cocoon threw
exception
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:963)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j
ava:3420)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:
3608)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja
va:821)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeploy
er.java:307)
at
org.apache.catalina.core.StandardHost.install(StandardHost.java:772)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:492)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:400)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:718)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:
358)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu
pport.java:166)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at
org.apache.catalina.core.StandardService.start(StandardService.java:
497)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
----- Root Cause -----
java.lang.StackOverflowError
2004-04-22 11:59:18 StandardWrapper[/my-project:invoker]: Loading
container servlet invoker
- opening the webapp /my-project again gives the following error:
HTTP Status 500 -
type: Exception report
message:
description: The server encountered an internal error () that prevented
it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet Cocoon threw
exception
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:963)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:
668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
onnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:619)
at java.lang.Thread.run(Thread.java:552)
root cause
java.lang.StackOverflowError
Apache Tomcat/4.1.24-LE-jdk14
>>> You are right the need for cocoon-live.xconf should be removed by
>>> this work. But I don't know if Nikola Ken has tested this, I don't
>>> think this is one of his use cases. Perhaps you could test it for
>>> us?
>> I would be happy to, anytime (almost;)
>
> If you are not urgently requiring this to work then I recomend you try
> out the branch Nikolen Ken is working on (see other message in this
> thread for instructions). Be aware this work is not complete though.
I am presently doing most of my work in Forrest 0.5.1, but would like
to move to 0.6beta as soon as it is stable enough - there are several
features coming with 0.6 that I need. That is, I had hoped that the
present revision would be stable, since it worked with editing the
cocoon.xconf manually. But not this time:-(
The crash is pretty bad, so others should be warned at least. Other
than that - I'm not sure there's any point in fixing the bug if there's
another solution coming soon.
So, I am not urgently needing this to work, but as 0.5.1 does fullfill
my immediate requirements, I'll wait until Nicola Ken's work is more
complete.
Sjur
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in
WAR
Posted by Ross Gardler <rg...@apache.org>.
Sjur Nørstebø Moshagen wrote:
> På 20. apr. 2004 kl. 22.54 skrev Ross Gardler:
>
>> issues@cocoondev.org wrote:
>>
>>> Message:
>>> Description:
>>> When building a war file, the generated WEB-INF/cocoon.xconf file
>>> contains absolute paths to the resources, content, catalogs etc of
>>> the webapp as found on the development computer. This brakes the war
>>> when installed in a servlet container. Manually editing cocoon.xconf
>>> after installing the war fixes the issue.
>>
>>
>> This was broken by a recent commit that prevents cocoon-live.xconf
>> from being configured and replacing cocoon.xconf when building the
>> war. This was pointed out on the list but the change was never
>> reverted (and I'm afraid I have not had the time to download and
>> configure SVN so I'm unable to do this).
>
>
> Sorry I didn't catch that thread - I'm still pretty new to Forrest,
> and things I don't understand tend to go unnoticed.
No, we should have fixed it in SVN rather than waiting for a user to
find the problem - our mistake not yours.
>> If you uncomment the lines in the webapp target that copy
>> cocoon-live.xconf into the webapp directory it should work.
>
>
> I tried, but with disastrous results, of which I don't understand
> anything:
<snip/>
> root cause
> java.lang.StackOverflowError
> --------- end of error msg ---------
>
Interesting, this needs exploring, although I doubt I will find the time
(it is the last week of teaching before exams, after this week my time
is my own again).
> If I then go back and comment out the said block again (producing a
> bogus cocoon.xconf, which I then would edit manually), I now get a
> similar error:
>
<snip/>
> root cause
> java.lang.StackOverflowError
> [an endless list similar to the above]
> --------- end of error msg ---------
Hmmm....
You didn't get this error before temporarliy editing the ANT file. Try
deleting the build directory and rebuilding to see if it works OK. This
should be done in the build anyway, but lets just check that out.
Also try doing forrest run - does everything work OK then?
>> You are right the need for cocoon-live.xconf should be removed by
>> this work. But I don't know if Nikola Ken has tested this, I don't
>> think this is one of his use cases. Perhaps you could test it for us?
>
>
> I would be happy to, anytime (almost;)
If you are not urgently requiring this to work then I recomend you try
out the branch Nikolen Ken is working on (see other message in this
thread for instructions). Be aware this work is not complete though.
(although I know Nikolen Ken rarely starts commiting to SVN unless he
knows he has the time to finish the job so unless something critical
gets in his way we can expect it working pretty soon)
Ross
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in WAR
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
På 20. apr. 2004 kl. 22.54 skrev Ross Gardler:
> issues@cocoondev.org wrote:
>> Message:
>> Description:
>> When building a war file, the generated WEB-INF/cocoon.xconf file
>> contains absolute paths to the resources, content, catalogs etc of
>> the webapp as found on the development computer. This brakes the war
>> when installed in a servlet container. Manually editing cocoon.xconf
>> after installing the war fixes the issue.
>
> This was broken by a recent commit that prevents cocoon-live.xconf
> from being configured and replacing cocoon.xconf when building the
> war. This was pointed out on the list but the change was never
> reverted (and I'm afraid I have not had the time to download and
> configure SVN so I'm unable to do this).
Sorry I didn't catch that thread - I'm still pretty new to Forrest,
and things I don't understand tend to go unnoticed.
> If you uncomment the lines in the webapp target that copy
> cocoon-live.xconf into the webapp directory it should work.
I tried, but with disastrous results, of which I don't understand
anything:
--------- start of error msg ---------
exception
javax.servlet.ServletException: Servlet.init() for servlet Cocoon threw
exception
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:963)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:
668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
onnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:619)
at java.lang.Thread.run(Thread.java:552)
root cause
java.lang.StackOverflowError
--------- end of error msg ---------
If I then go back and comment out the said block again (producing a
bogus cocoon.xconf, which I then would edit manually), I now get a
similar error:
--------- start of error msg ---------
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet Cocoon threw
exception
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav
a:963)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:
668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa
lve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i
nvokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
594)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC
onnection(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:
565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:619)
at java.lang.Thread.run(Thread.java:552)
root cause
java.lang.StackOverflowError
[an endless list similar to the above]
--------- end of error msg ---------
The webapp used was a fresh seed, with the samples removed (thus, only
the index and status files, nothing more. Only default settings in
forrest.properties and skinconf.xml.
Note: I did a svn update before I made the changes in the webapp
target, but the only affected files from yesterday were:
a80-186-85-67:~/svn-forrest/forrest sjur$ svn update
A legal/jsch-0.1.14.jar.license.txt
U src/documentation/content/xdocs/forrestbot.xml
A tools/ant/lib/jsch-0.1.14.jar
A tools/ant/lib/ant-jsch.jar
U scratchpad/forrestbot2/core/getsrc.xml
U scratchpad/forrestbot2/core/deploy.xml
Updated to revision 10146.
As far as I can see, none of these updates/additions should affect the
making of the webapp/war, but except for commenting in/out the
cocoon-live.xconf copying block, no other changes has been done. So
somehow the build process has been mixed up.
> You are right the need for cocoon-live.xconf should be removed by this
> work. But I don't know if Nikola Ken has tested this, I don't think
> this is one of his use cases. Perhaps you could test it for us?
I would be happy to, anytime (almost;)
Sjur
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in
WAR
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> issues@cocoondev.org wrote:
...
> > [While I wrote this bug report, nicolaken wrote an UPDATE about what
> > looks like the same issue. But since I could not find a bug report
> > covering it, I found it better to file the report as not to forget to
> > test against it later on.]
>
> You are right the need for cocoon-live.xconf should be removed by this
> work. But I don't know if Nikola Ken has tested this, I don't think this
> is one of his use cases.
I have not tested it, but in fact it's actually part of the work :-)
When it finds forrest.home and project.home specified, it uses them. If
not, it resolves relative to ".", which is the webapp context. IOW when
it's all set up correctly there is no more need for a separate xconf,
but I still need to finish the work on the branch.
> Perhaps you could test it for us?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [issues] Created: (FOR-133) Cocoon.xconf is misconfigured in
WAR
Posted by Ross Gardler <rg...@apache.org>.
issues@cocoondev.org wrote:
> Message:
>
> Description:
> When building a war file, the generated WEB-INF/cocoon.xconf file contains absolute paths to the resources, content, catalogs etc of the webapp as found on the development computer. This brakes the war when installed in a servlet container. Manually editing cocoon.xconf after installing the war fixes the issue.
>
This was broken by a recent commit that prevents cocoon-live.xconf from
being configured and replacing cocoon.xconf when building the war. This
was pointed out on the list but the change was never reverted (and I'm
afraid I have not had the time to download and configure SVN so I'm
unable to do this).
If you uncomment the lines in the webapp target that copy
cocoon-live.xconf into the webapp directory it should work.
> [While I wrote this bug report, nicolaken wrote an UPDATE about what
> looks like the same issue. But since I could not find a bug report
> covering it, I found it better to file the report as not to forget to
> test against it later on.]
You are right the need for cocoon-live.xconf should be removed by this
work. But I don't know if Nikola Ken has tested this, I don't think this
is one of his use cases. Perhaps you could test it for us?
Ross