[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508800#comment-13508800
]
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
http://localhost:8888/mywebapp/
http://localhost:8888/mywebapp2/mysite/
http://localhost:8888/mywebapp2/mysite2/
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.
[1] https://github.com/ilgrosso/cocoon3EmptyProject
> 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
> 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,
> cocoon-servlet-service-impl.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
> 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
