cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: [DISCUSS] Fix for COCOON3-105
Date Fri, 07 Dec 2012 11:49:47 GMT
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=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.

-- 
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


Mime
View raw message