Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Mon, 3 Dec 2012 15:31:58 +0000 (UTC)
From: =?utf-8?Q?Francesco_Chicchiricc=C3=B2_=28JIRA=29?= <jira@apache.org>
To: dev@cocoon.apache.org
Message-ID: <1375040647.53637.1354548718689.JavaMail.jiratomcat@arcas>
In-Reply-To: <917823667.77020.1347569467481.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (COCOON3-105) webapp fails if on the same
 servlet container is a c2.2.1 or other c3 webapp running
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COCOON3-105?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D135=
08800#comment-13508800 ]=20

Francesco Chicchiricc=C3=B2 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 tr=
oubles when applying: if you find any .rej or .orig files (after applicatio=
n), 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 imp=
lementation, working together with the JVM's jar:/ protocol.

I have also prepared a demo project for this [1]: after having "mvn clean i=
nstall" 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 dis=
tinct 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 Classpat=
hURLStreamHandlerFactory class is provided - I've put this class in cocoon-=
servlet but we can think to move it to cocoon-servlet-service-impl, for exa=
mple.

[1] https://github.com/ilgrosso/cocoon3EmptyProject
               =20
> webapp fails if on the same servlet container is a c2.2.1 or other c3 web=
app running=20
> -------------------------------------------------------------------------=
------------
>
>                 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=C3=B2
>            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]=20
> [INFO] myparent .......................................... SUCCESS [1.163=
s]
> [INFO] myblock ........................................... SUCCESS [3.611=
s]
> [INFO] mywebapp .......................................... SUCCESS [1.924=
s]
> [INFO] myblock2 .......................................... SUCCESS [1.498=
s]
> [INFO] mywebapp2 ......................................... SUCCESS [1.230=
s]
> [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 runni=
ng instance. You should see the welcome page under something like http://lo=
calhost:8080/mywebapp-1.0-SNAPSHOT/
> side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a Strin=
gIndexOutOfBoundsException 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=20
> http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> will return a blank page and in=20
> /.../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.XMLSi=
temapServlet - Can't initialize the RequestProcessor correctly.
> org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't b=
uild sitemap from blockcontext:/myblock2/sitemap.xmap
> =09at org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:=
70) ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> =09at org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(Reques=
tProcessor.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' deplo=
yed. The available blocks are {myblock=3Dfile:/home/thorsten/src/apache/apa=
che-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/mybl=
ock/}.
> =09at org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConn=
ection(BlockContextURLConnection.java:76) ~[cocoon-block-deployment-1.2.1.j=
ar:1.2.1]
> =09at org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInpu=
tStream(BlockContextURLConnection.java:56) ~[cocoon-block-deployment-1.2.1.=
jar:1.2.1]
> =09at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
> =09at org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:=
65) ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> =09... 46 common frames omitted
> As you see the blockcontext from the 2nd app is the one from the first EV=
EN if they are deployed as 2 different webapps!
> Now stop the tomcat and start again.=20
> Depending which app you request on a fresh stared tomcat that one will wo=
rk the other will present a blank page and the log will say something like:
> Caused by: java.lang.RuntimeException: There is no block 'myblock' deploy=
ed. The available blocks are {myblock2=3Dfile:/home/thorsten/src/apache/apa=
che-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myb=
lock2/}.
> 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 th=
en you can actually see both working ONLY if you first request the c3 and t=
hen 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 fo=
r the cause of the problem).
> Now shutdown and start with both deployed the c2.2 always works and the c=
3 not.=20
> I see the problem for our client coming when we introduced=20
> <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletC=
ontextListener</listener-class>
> The main observation is that the c2 one seems to much more presistence bu=
t that can come the way of invocation (on-demand vs. startup). Anyway the b=
lockcontext 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 administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira