Thorsten Scherler created COCOON3-105:
-----------------------------------------
Summary: webapp fails if on the same servlet container is a c2.2.1
or other c3 webapp running
Key: COCOON3-105
URL: https://issues.apache.org/jira/browse/COCOON3-105
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Priority: Blocker
I noticed that you cannot run 2 c3 based war in a tomcat.
To reproduce:
- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype
where webapp depends on block one and webapp2 depends on block2.
My sample was:
[INFO] Reactor Summary:
[INFO]
[INFO] myparent .......................................... SUCCESS [1.163s]
[INFO] myblock ........................................... SUCCESS [3.611s]
[INFO] mywebapp .......................................... SUCCESS [1.924s]
[INFO] myblock2 .......................................... SUCCESS [1.498s]
[INFO] mywebapp2 ......................................... SUCCESS [1.230s]
[INFO] ------------------------------------------------------------------------
Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it
before you start to webapp or if you have it enable deploy it on a running
instance. You should see the welcome page under something like
http://localhost:8080/mywebapp-1.0-SNAPSHOT/
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Now if you deploy the second webapp on a running instance it will deploy
without problem but requesting
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build
sitemap from blockcontext:/myblock2/sitemap.xmap
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed.
The available blocks are
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
... 46 common frames omitted
As you see the blockcontext from the 2nd app is the one from the first EVEN if
they are deployed as 2 different webapps!
Now stop the tomcat and start again.
Depending which app you request on a fresh stared tomcat that one will work the
other will present a blank page and the log will say something like:
Caused by: java.lang.RuntimeException: There is no block 'myblock' deployed.
The available blocks are
{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.
In this case I requested the 2nd first.
Originally I found out because we have a client that has some c3 and a c2.2.1
app (not) running aside. So in case you create a 2.2.1 webapp from the
archetype as described http://cocoon.apache.org/2.2/1159_1_1.html and use it
instead of the c3 2nd webapp you will get similar results.
If you start first with the 1st c3 and then deploy the c2.2 on the run then you
can actually see both working ONLY if you first request the c3 and then deploy
and then see the c2. In case you do not request the c3 prior it will not work
once you requested the c2 (which maybe present interesting for the cause of the
problem).
Now shutdown and start with both deployed the c2.2 always works and the c3 not.
I see the problem for our client coming when we introduced
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
The main observation is that the c2 one seems to much more presistence but that
can come the way of invocation (on-demand vs. startup). Anyway the blockcontext
should never be shared between two different servlets.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
