[ 
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

Reply via email to