cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jos Snellings <jos.snelli...@upperware.biz>
Subject Re: [DISCUSS] Fix for COCOON3-105
Date Fri, 07 Dec 2012 12:09:08 GMT
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.Pelssers@nxp.com>wrote:

> I might have time to check this weekend but I can't guarantee it.
>
> Robby
>
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@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>

Mime
View raw message