cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò (JIRA) <>
Subject [jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
Date Mon, 03 Dec 2012 15:31:58 GMT


Francesco Chicchiriccò commented on COCOON3-105:

Please evaluate the attached patch (COCOON3-105.patch).

The patch is quite pervasive and I've seen that it might also cause some troubles when applying:
if you find any .rej or .orig files (after application), please remove.

This patch basically removes any reference to the blockcontext:/ protocol - as you can see
there is no more dependency on cocon-block-deployment.
The blockcontext:/ protocol has been replaced by a classpath:/ protocol implementation, working
together with the JVM's jar:/ protocol.

I have also prepared a demo project for this [1]: after having "mvn clean install" on the
patched C3 source tree, just clone, switch to branch COCOON3-105 and compile by running

mvn clean package

then launch via

mvn cargo:run

You will get an Apache Tomcat instance listening on 8888 containing two distinct C3 webapps;
access URLs are


e.g. 3 distinct blocks across 2 distinct webapps.

Please note that this fix should also work for C2.2, as far as the ClasspathURLStreamHandlerFactory
class is provided - I've put this class in cocoon-servlet but we can think to move it to cocoon-servlet-service-impl,
for example.

> webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

> -------------------------------------------------------------------------------------
>                 Key: COCOON3-105
>                 URL:
>             Project: Cocoon 3
>          Issue Type: Bug
>          Components: cocoon-webapp
>    Affects Versions: 3.0.0-beta-1
>            Reporter: Thorsten Scherler
>            Assignee: Francesco Chicchiriccò
>            Priority: Blocker
>             Fix For: 3.0.0-beta-1
>         Attachments: COCOON3-105.npe.diff, COCOON3-105.patch, COCOON3-105.patch, cocoon-block-deployment.patch,
> 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 ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> 	at org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(
> ...
> 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(
> 	at org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(
> 	at ~[na:1.6.0_30]
> 	at ~[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
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:

View raw message