In shorthand: What are the implications then? Bottomline: - "a block context" is addressable within the sitemap load resource from another block context is possible via 'classpath'. The root of every block is available on the classpath? - different web applications relying on cocoon3 can deploy blocks with the same name they won't interfere with each other?
Best, Jos On Fri, Dec 7, 2012 at 12:56 PM, Robby Pelssers <robby.pelss...@nxp.com>wrote: > I might have time to check this weekend but I can't guarantee it. > > Robby > > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Friday, December 07, 2012 12:50 PM > To: dev@cocoon.apache.org > Subject: Re: [DISCUSS] Fix for COCOON3-105 > > Hi all, > any reaction on this? Shall I just apply such huge patch without anyone > else's confirmation??!? > > Regards. > > On 03/12/2012 16:38, Francesco Chicchiriccò wrote: > > Hi all, > > I have finally elaborated a fix for COCOON3-105 and now I am able to > > run more C3-based webapps in the same servlet container. > > > > I have also added a comment explaining the way I have fixed the issue: > > as you can see, it is a considerable change, so I'd like to get your > > feedback before applying. > > > > Please take a look and let me know. > > > > Regards. > > > > On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: > >> [ > >> https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian. > >> jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1 > >> 3508800#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:7 > >>> 0) ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT] > >>> at > >>> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(Request > >>> Processor.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.getConne > >>> ction(BlockContextURLConnection.java:76) > >>> ~[cocoon-block-deployment-1.2.1.jar:1.2.1] > >>> at > >>> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInput > >>> Stream(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:6 > >>> 5) ~[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.BlockDeploymentSer > >>> vletContextListener</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. > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/ > > > -- All generous minds have a horror of what are commonly called "Facts". They are the brute beasts of the intellectual domain. -- Thomas Hobbes <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>
