Hi Thorsten, I believe having encountered this problem once. However, it is not systematic.
Jos On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689] > > Thorsten Scherler commented on COCOON3-105: > ------------------------------------------- > > The problem lies in in > org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory.createURLStreamHandler > here we create a BlockContextURLStreamHandler extends URLStreamHandler > > Regarding URLStreamHandler > /** > * The abstract class <code>URLStreamHandler</code> is the common > * superclass for all stream protocol handlers. A stream protocol > * handler knows how to make a connection for a particular protocol > * type, such as <code>http</code>, <code>ftp</code>, or > * <code>gopher</code>. > * <p> > * In most cases, an instance of a <code>URLStreamHandler</code> > * subclass is not created directly by an application. Rather, the > * first time a protocol name is encountered when constructing a > * <code>URL</code>, the appropriate stream protocol handler is > * automatically loaded.*/ > > Which is exactly the problem in our case. Once the URLStreamHandler is > setup for the first blockcontext as protocol the second servlet will > directly use the java.net.URLStreamHandler and use that protocol. > > Meaning if you start tomcat with both apps deployed the first request of > the first app decides which blockcontext will be associate with the block > context protocol > > That happens in BlockContextURLStreamHandlerFactory where > createURLStreamHandler is only called once with the first request the > second then uses the old block context. > > > > 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.htmland 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 > -- The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
