You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Thorsten Scherler (JIRA)" <ji...@apache.org> on 2012/09/17 00:06:07 UTC
[jira] [Commented] (COCOON3-105) webapp fails if on the same
servlet container is a c2.2.1 or other c3 webapp running
[ 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.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.
--
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
Re: [jira] [Commented] (COCOON3-105) webapp fails if on the same
servlet container is a c2.2.1 or other c3 webapp running
Posted by Thorsten Scherler <sc...@gmail.com>.
On 09/17/2012 07:16 AM, Jos Snellings wrote:
> Hi Thorsten,
>
> I believe having encountered this problem once.
> However, it is not systematic.
Hi Joe,
I think I pinned down the problem.
We use java.net.urlHandler which means we only get init once. I am ATM
reviewing the servlet handler and here we do the resolving part in the
Connection part.
I think the blockcontextHandler needs to loose the this.blockcontext
part, this would need to be resolved in the actual
BlockContextURLConnection to resolve against only for the current
servlet specific registered blocks.
salu2
>
> Jos
>
> On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA)
> <jira@apache.org <ma...@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.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.
>
> --
> 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
>
>
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: [jira] [Commented] (COCOON3-105) webapp fails if on the same
servlet container is a c2.2.1 or other c3 webapp running
Posted by Jos Snellings <jo...@upperware.biz>.
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)
<ji...@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