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: [jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
Date Mon, 17 Sep 2012 05:16:31 GMT
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)
<jira@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

Mime
View raw message