Discussion:
[jira] [Created] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
Thorsten Scherler (JIRA)
2012-09-13 20:51:07 UTC
Permalink
Thorsten Scherler created COCOON3-105:
-----------------------------------------

Summary: 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
Thorsten Scherler (JIRA)
2012-09-16 22:06:07 UTC
Permalink
[ 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.
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
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.
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
Jos Snellings
2012-09-17 05:16:31 UTC
Permalink
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)
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689]
-------------------------------------------
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.
Post by Thorsten Scherler (JIRA)
webapp fails if on the same servlet container is a c2.2.1 or other c3
webapp running
-------------------------------------------------------------------------------------
Post by Thorsten Scherler (JIRA)
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.
- 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.
[INFO]
[INFO] myparent .......................................... SUCCESS
[1.163s]
Post by Thorsten Scherler (JIRA)
[INFO] myblock ........................................... SUCCESS
[3.611s]
Post by Thorsten Scherler (JIRA)
[INFO] mywebapp .......................................... SUCCESS
[1.924s]
Post by Thorsten Scherler (JIRA)
[INFO] myblock2 .......................................... SUCCESS
[1.498s]
Post by Thorsten Scherler (JIRA)
[INFO] mywebapp2 ......................................... SUCCESS
[1.230s]
Post by Thorsten Scherler (JIRA)
[INFO]
------------------------------------------------------------------------
Post by Thorsten Scherler (JIRA)
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/
Post by Thorsten Scherler (JIRA)
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Post by Thorsten Scherler (JIRA)
Now if you deploy the second webapp on a running instance it will deploy
without problem but requesting
Post by Thorsten Scherler (JIRA)
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
Post by Thorsten Scherler (JIRA)
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't
build sitemap from blockcontext:/myblock2/sitemap.xmap
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
...
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/}.
Post by Thorsten Scherler (JIRA)
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
Post by Thorsten Scherler (JIRA)
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
... 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!
Post by Thorsten Scherler (JIRA)
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
Post by Thorsten Scherler (JIRA)
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/}.
Post by Thorsten Scherler (JIRA)
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.
Post by Thorsten Scherler (JIRA)
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).
Post by Thorsten Scherler (JIRA)
Now shutdown and start with both deployed the c2.2 always works and the
c3 not.
Post by Thorsten Scherler (JIRA)
I see the problem for our client coming when we introduced
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
Post by Thorsten Scherler (JIRA)
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
2012-09-17 10:02:41 UTC
Permalink
Post by Jos Snellings
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
Post by Jos Snellings
Jos
On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA)
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689
]
-------------------------------------------
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.
Post by Thorsten Scherler (JIRA)
webapp fails if on the same servlet container is a c2.2.1 or
other c3 webapp running
-------------------------------------------------------------------------------------
Post by Thorsten Scherler (JIRA)
Key: COCOON3-105
https://issues.apache.org/jira/browse/COCOON3-105
Post by Thorsten Scherler (JIRA)
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.
- 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.
[INFO]
[INFO] myparent ..........................................
SUCCESS [1.163s]
Post by Thorsten Scherler (JIRA)
[INFO] myblock ...........................................
SUCCESS [3.611s]
Post by Thorsten Scherler (JIRA)
[INFO] mywebapp ..........................................
SUCCESS [1.924s]
Post by Thorsten Scherler (JIRA)
[INFO] myblock2 ..........................................
SUCCESS [1.498s]
Post by Thorsten Scherler (JIRA)
[INFO] mywebapp2 .........................................
SUCCESS [1.230s]
Post by Thorsten Scherler (JIRA)
[INFO]
------------------------------------------------------------------------
Post by Thorsten Scherler (JIRA)
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/
Post by Thorsten Scherler (JIRA)
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will
throw a StringIndexOutOfBoundsException but that is another ticket
I guess.
Post by Thorsten Scherler (JIRA)
Now if you deploy the second webapp on a running instance it
will deploy without problem but requesting
Post by Thorsten Scherler (JIRA)
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
Can't build sitemap from blockcontext:/myblock2/sitemap.xmap
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
...
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/}.
Post by Thorsten Scherler (JIRA)
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
Post by Thorsten Scherler (JIRA)
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
Post by Thorsten Scherler (JIRA)
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]
Post by Thorsten Scherler (JIRA)
... 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!
Post by Thorsten Scherler (JIRA)
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
Post by Thorsten Scherler (JIRA)
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/}.
Post by Thorsten Scherler (JIRA)
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.
Post by Thorsten Scherler (JIRA)
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).
Post by Thorsten Scherler (JIRA)
Now shutdown and start with both deployed the c2.2 always works
and the c3 not.
Post by Thorsten Scherler (JIRA)
I see the problem for our client coming when we introduced
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
Post by Thorsten Scherler (JIRA)
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
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/
Thorsten Scherler (JIRA)
2012-09-17 10:58:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Scherler updated COCOON3-105:
--------------------------------------

Attachment: COCOON3-105.npe.diff

This is a first step to remove the need of the blocktontext in the constructor.

However it works fine with the first sevlet however the second will fail with a NPE because
ServletContext servletContext = CallStackHelper.getCurrentServletContext();
is null
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Thorsten Scherler (JIRA)
2012-09-17 11:02:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456938#comment-13456938 ]

Thorsten Scherler commented on COCOON3-105:
-------------------------------------------

We need to find a way to get the
this.blockContexts = (Map<String, String>) servletContext
.getAttribute(BlockDeploymentServletContextListener.BLOCK_CONTEXT_MAP);

Somebody knows why servletContext = CallStackHelper.getCurrentServletContext() can become null? I need to attend now some urgent matter so I will not be able to put more hours into the issue but I will attend it later on and follow the comment flow.
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-09-20 15:08:08 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò updated COCOON3-105:
-------------------------------------------

Attachment: cocoon-servlet-service-impl.patch
cocoon-block-deployment.patch

These patches move the logic for handling blockcontext:// URLs from implicit (via BlockContextURLStreamHandlerFactory) to explicit, inside ServletServiceContext.getResource()

I haven't been able to empower JNet for narrowing the scope of BlockContextURLStreamHandlerFactory nor I could solve by AOP.

By applying these patches to respectively cocoon-block-deployment and cocoon-servlet-service-impl, you can run any number of C3 webapps inside the same container.
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-09-20 15:08:09 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò updated COCOON3-105:
-------------------------------------------

Status: On Hold (was: Open)

With the patches I have provided, this issue is solved.

Anyway I would like to hear if anyone sees problems in making ServletServiceContext aware of blockcontext:// URL protocol.
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Thorsten Scherler (JIRA)
2012-09-24 17:04:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461913#comment-13461913 ]

Thorsten Scherler commented on COCOON3-105:
-------------------------------------------

Hi Francesco, first of all thank you very much for the patch.

I tried the patches, but with them my webapps actually did not work at all the first time.

After I patched them the correct way everything seems to work as expected.

Regarding the dep to block from ssc I am not sure, but this way the blockcontext is again context aware and unique.

I will do some more testing and finally try to apply the changes in the client project.

Thx again
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-09-25 07:00:08 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462502#comment-13462502 ]

Francesco Chicchiriccò commented on COCOON3-105:
------------------------------------------------

You're welcome Thorsten!

If no one has objections, I would apply the attached patches to cocoon-block-deployment and cocoon-servlet-service, deploy the new SNAPSHOT artifacts and make C3 to use such SNAPSHOTs.

Afterwards we can think of making a new release for these two subprojects.
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Thorsten Scherler (JIRA)
2012-09-25 10:08:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462618#comment-13462618 ]

Thorsten Scherler commented on COCOON3-105:
-------------------------------------------

Yeah, go ahead.

If you can manage to seperate the formating changes from the real ones for the commit that would awesome. If you want I can do that, just shout.
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-09-25 10:10:08 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462622#comment-13462622 ]

Francesco Chicchiriccò commented on COCOON3-105:
------------------------------------------------

It would be nice if you can take care of this, I am bit in a little tornado these days :-)
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-09-25 10:12:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462622#comment-13462622 ]

Francesco Chicchiriccò edited comment on COCOON3-105 at 9/25/12 9:10 PM:
-------------------------------------------------------------------------

It would be nice if you can take care of this, I am lost in a little tornado these days :-)

was (Author: ilgrosso):
It would be nice if you can take care of this, I am bit in a little tornado these days :-)
Post by Thorsten Scherler (JIRA)
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
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Thorsten Scherler (JIRA)
2012-09-25 11:54:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Scherler closed COCOON3-105.
-------------------------------------

Resolution: Fixed
Fix Version/s: 3.0.0-beta-1

last commit around the issue r1389820.

snapshots are deployed as well.
Post by Thorsten Scherler (JIRA)
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
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Hudson (JIRA)
2012-09-25 16:16:08 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462907#comment-13462907 ]

Hudson commented on COCOON3-105:
--------------------------------

Integrated in Cocoon-trunk #214 (See [https://builds.apache.org/job/Cocoon-trunk/214/])
Using updated subprojects as per COCOON3-105 (Revision 1389908)

Result = UNSTABLE
ilgrosso : http://svn.apache.org/viewvc/?view=rev&rev=1389908
Files :
* /cocoon/cocoon3/trunk/parent/pom.xml
Post by Thorsten Scherler (JIRA)
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
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Hudson (JIRA)
2012-09-25 17:12:07 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462983#comment-13462983 ]

Hudson commented on COCOON3-105:
--------------------------------

Integrated in Cocoon-trunk #215 (See [https://builds.apache.org/job/Cocoon-trunk/215/])
[COCOON3-105] Reverting to stable versions: with SNAPSHOTs IT fail because of 'MalformedURLException: unknown protocol: blockcontext' (Revision 1389975)

Result = SUCCESS
ilgrosso : http://svn.apache.org/viewvc/?view=rev&rev=1389975
Files :
* /cocoon/cocoon3/trunk/parent/pom.xml
Post by Thorsten Scherler (JIRA)
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
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-12-03 11:19:58 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò reopened COCOON3-105:
--------------------------------------------

Assignee: Francesco Chicchiriccò
Post by Thorsten Scherler (JIRA)
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, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-12-03 12:17:58 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508683#comment-13508683 ]

Francesco Chicchiriccò commented on COCOON3-105:
------------------------------------------------

Patches applied reverted at [1] and [2], working on an alternative fix.

[1] http://svn.apache.org/viewvc?rev=1416462&view=rev
[2] http://svn.apache.org/viewvc?rev=1416463&view=rev
Post by Thorsten Scherler (JIRA)
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, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-12-03 15:11:59 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò updated COCOON3-105:
-------------------------------------------

Attachment: COCOON3-105.patch
Post by Thorsten Scherler (JIRA)
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, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-12-03 15:31:58 UTC
Permalink
[ 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
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
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.
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
Francesco Chicchiriccò
2012-12-03 15:38:28 UTC
Permalink
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.
Post by Francesco Chicchiriccò (JIRA)
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508800#comment-13508800 ]
------------------------------------------------
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
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
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.
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
--
Dott. Francesco Chicchiriccò
Tel +393290573276

Amministratore unico @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

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

"To Iterate is Human, to Recurse, Divine"
(James O. Coplien, Bell Labs)
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Francesco Chicchiriccò
2012-12-07 11:49:47 UTC
Permalink
Hi all,
any reaction on this? Shall I just apply such huge patch without anyone
else's confirmation??!?

Regards.
Post by Francesco Chicchiriccò
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.
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.
Post by Francesco Chicchiriccò (JIRA)
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508800#comment-13508800
]
------------------------------------------------
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
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
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
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/
Robby Pelssers
2012-12-07 11:56:53 UTC
Permalink
I might have time to check this weekend but I can't guarantee it.

Robby

-----Original Message-----
From: Francesco Chicchiriccò [mailto:***@apache.org]
Sent: Friday, December 07, 2012 12:50 PM
To: ***@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.
Post by Francesco Chicchiriccò
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.
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.
Post by Thorsten Scherler (JIRA)
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1
3508800#comment-13508800
]
------------------------------------------------
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
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
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
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 P
Jos Snellings
2012-12-07 12:09:08 UTC
Permalink
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
Post by Robby Pelssers
I might have time to check this weekend but I can't guarantee it.
Robby
-----Original Message-----
Sent: Friday, December 07, 2012 12:50 PM
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.
Post by Francesco Chicchiriccò
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.
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.
Post by Thorsten Scherler (JIRA)
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1
3508800#comment-13508800
]
------------------------------------------------
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
Post by Thorsten Scherler (JIRA)
webapp fails if on the same servlet container is a c2.2.1 or other
c3 webapp running
--------------------------------------------------------------------
-----------------
Key: COCOON3-105
https://issues.apache.org/jira/browse/COCOON3-105
Post by Francesco Chicchiriccò
Post by Thorsten Scherler (JIRA)
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
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/}.
Post by Francesco Chicchiriccò
Post by Thorsten Scherler (JIRA)
Post by Thorsten Scherler (JIRA)
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
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/}.
Post by Francesco Chicchiriccò
Post by Thorsten Scherler (JIRA)
Post by Thorsten Scherler (JIRA)
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>
Francesco Chicchiriccò
2012-12-07 12:33:16 UTC
Permalink
Post by Jos Snellings
In shorthand: What are the implications then?
For users? Just the servlet:context declaration, from

<servlet:context mount-path=""
context-path="blockcontext:/cocoon-sample/" />

to

<servlet:context mount-path=""
context-path="jar:classpath:lib/${project.build.finalName}.jar!/COB-INF/"/>


However, in order to be consistent with RCL, you should also add - in
the 'dev' profile -

<servlet:context mount-path="" context-path="classpath:/COB-INF/"/>


The provided patch contains the needed changes for archetypes so that
new blocks are already created with the new way.

In practice, this patch removes the need of the 'blockcontext:/'
protocol that has proven to make unfeasible to deploy two distinct C3
block-enabled webapps in the same container.

As a side note, you can still use the blockcontext:/ protocol, but
you'll need to manually add the cocoon-block-deployment dependency.
Let's say that this patch puts the blockcontext:/ protocol in a sort of
'deprecated' state.
Post by Jos Snellings
- "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?
Everything should be working in the same way.
Post by Jos Snellings
- different web applications relying on cocoon3 can deploy blocks with
the same name
they won't interfere with each other?
Correct.
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Leonardo Miceli
2012-12-20 12:45:00 UTC
Permalink
Hello
Post by Francesco Chicchiriccò
Post by Jos Snellings
In shorthand: What are the implications then?
(...)
Post by Francesco Chicchiriccò
Post by Jos Snellings
- "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?
Everything should be working in the same way.
Can you please tell me how can I address block_A's sitemap from from
block_B's sitemap?
I have used *blockcontext:/* for this before.

Best Regards,

Leonardo.
Francesco Chicchiriccò
2012-12-20 13:05:41 UTC
Permalink
Post by Leonardo Miceli
Hello
Post by Francesco Chicchiriccò
Post by Jos Snellings
In shorthand: What are the implications then?
(...)
Post by Francesco Chicchiriccò
Post by Jos Snellings
- "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?
Everything should be working in the same way.
Can you please tell me how can I address block_A's sitemap from from
block_B's sitemap?
I have used *blockcontext:/* for this before.
This should work In the same way as in *servlet-service.xml, e.g. by
replacing

blockcontext:/otherblock/BLA

with

jar:classpath:lib/otherblock.jar!/COB-INF/BLA


Could you provide some more concrete example, in case this is not just
working? Thanks.

Regards.
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Thorsten Scherler
2013-01-14 15:20:25 UTC
Permalink
Post by Francesco Chicchiriccò
Post by Leonardo Miceli
Hello
Post by Francesco Chicchiriccò
Post by Jos Snellings
In shorthand: What are the implications then?
(...)
Post by Francesco Chicchiriccò
Post by Jos Snellings
- "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?
Everything should be working in the same way.
Can you please tell me how can I address block_A's sitemap from from
block_B's sitemap?
I have used *blockcontext:/* for this before.
This should work In the same way as in *servlet-service.xml, e.g. by
replacing
blockcontext:/otherblock/BLA
with
jar:classpath:lib/otherblock.jar!/COB-INF/BLA
Hi, I just tried the above in another project but using it in the
sitemap I get
java.net.MalformedURLException: invalid url:
classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
(java.net.MalformedURLException: unknown protocol: classpath)

I am trying to use a central module to store common xsl that I need both
in cocoon and in my java code.

salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/
Francesco Chicchiriccò
2013-01-17 09:23:26 UTC
Permalink
Post by Thorsten Scherler
[...]
Post by Francesco Chicchiriccò
Post by Leonardo Miceli
Can you please tell me how can I address block_A's sitemap from from
block_B's sitemap?
I have used *blockcontext:/* for this before.
This should work In the same way as in *servlet-service.xml, e.g. by
replacing
blockcontext:/otherblock/BLA
with
jar:classpath:lib/otherblock.jar!/COB-INF/BLA
Hi, I just tried the above in another project but using it in the
sitemap I get
classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
(java.net.MalformedURLException: unknown protocol: classpath)
I am trying to use a central module to store common xsl that I need
both in cocoon and in my java code.
Hi Thorsten,
sorry for the delay, I am quite busy in this period on other projects.

Anyway, I'll try to check and get back asap to you.

Regards.
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Francesco Chicchiriccò
2013-01-19 13:23:22 UTC
Permalink
Post by Jos Snellings
Post by Thorsten Scherler
[...]
Post by Francesco Chicchiriccò
Post by Leonardo Miceli
Can you please tell me how can I address block_A's sitemap from
from block_B's sitemap?
I have used *blockcontext:/* for this before.
This should work In the same way as in *servlet-service.xml, e.g. by
replacing
blockcontext:/otherblock/BLA
with
jar:classpath:lib/otherblock.jar!/COB-INF/BLA
Hi, I just tried the above in another project but using it in the
sitemap I get
classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
(java.net.MalformedURLException: unknown protocol: classpath)
I am trying to use a central module to store common xsl that I need
both in cocoon and in my java code.
Hi Thorsten,
sorry for the delay, I am quite busy in this period on other projects.
Anyway, I'll try to check and get back asap to you.
Hi Thorsten,
I was finally able to make all needed checks and the good news is that
everything is working as expected.
From the error message you report above I guess that you are not using
the very latest C3 SNAPSHOT artifacts.

Anyway, I've updated the sample application [1] with some description
about how to run and what you get [2].

HTH
Regards.

[1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105
[2]
https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/README.md
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Thorsten Scherler
2013-02-05 15:10:04 UTC
Permalink
Post by Jos Snellings
Post by Jos Snellings
Post by Thorsten Scherler
[...]
Post by Francesco Chicchiriccò
Post by Leonardo Miceli
Can you please tell me how can I address block_A's sitemap from
from block_B's sitemap?
I have used *blockcontext:/* for this before.
This should work In the same way as in *servlet-service.xml, e.g.
by replacing
blockcontext:/otherblock/BLA
with
jar:classpath:lib/otherblock.jar!/COB-INF/BLA
Hi, I just tried the above in another project but using it in the
sitemap I get
classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl
(java.net.MalformedURLException: unknown protocol: classpath)
I am trying to use a central module to store common xsl that I need
both in cocoon and in my java code.
Hi Thorsten,
sorry for the delay, I am quite busy in this period on other projects.
Anyway, I'll try to check and get back asap to you.
Hi Thorsten,
I was finally able to make all needed checks and the good news is that
everything is working as expected.
From the error message you report above I guess that you are not using
the very latest C3 SNAPSHOT artifacts.
Anyway, I've updated the sample application [1] with some description
about how to run and what you get [2].
HTH
Thank you very much, the problem was indeed in the older snapshot.

salu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/
Thorsten Scherler
2013-02-05 15:32:08 UTC
Permalink
Post by Thorsten Scherler
Post by Jos Snellings
...
Hi Thorsten,
I was finally able to make all needed checks and the good news is
that everything is working as expected.
From the error message you report above I guess that you are not
using the very latest C3 SNAPSHOT artifacts.
Anyway, I've updated the sample application [1] with some description
about how to run and what you get [2].
HTH
Thank you very much, the problem was indeed in the older snapshot.
BTW

diff --git a/mysite2/pom.xml b/mysite2/pom.xml
index c5cb95b..e4c3527 100644
--- a/mysite2/pom.xml
+++ b/mysite2/pom.xml
@@ -17,7 +17,7 @@
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
- <artifactId>mysite2</artifactId>
+ <artifactId>mysite</artifactId>
<version>${project.version}</version>
</dependency>


alu2
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/
Francesco Chicchiriccò
2013-02-05 16:35:31 UTC
Permalink
Post by Thorsten Scherler
Post by Thorsten Scherler
Post by Jos Snellings
...
Hi Thorsten,
I was finally able to make all needed checks and the good news is
that everything is working as expected.
From the error message you report above I guess that you are not
using the very latest C3 SNAPSHOT artifacts.
Anyway, I've updated the sample application [1] with some
description about how to run and what you get [2].
HTH
Thank you very much, the problem was indeed in the older snapshot.
BTW
diff --git a/mysite2/pom.xml b/mysite2/pom.xml
index c5cb95b..e4c3527 100644
--- a/mysite2/pom.xml
+++ b/mysite2/pom.xml
@@ -17,7 +17,7 @@
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
- <artifactId>mysite2</artifactId>
+ <artifactId>mysite</artifactId>
<version>${project.version}</version>
</dependency>
Fixed, thanks:
https://github.com/ilgrosso/cocoon3EmptyProject/commit/820763548e1cc9270a1f76c27a0602544c5dbc31

Regards.
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Francesco Chicchiriccò
2012-12-03 15:38:16 UTC
Permalink
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.
Post by Francesco Chicchiriccò (JIRA)
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508800#comment-13508800 ]
------------------------------------------------
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
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
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.
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
--
Dott. Francesco Chicchiriccò
Tel +393290573276

Amministratore unico @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

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

"To Iterate is Human, to Recurse, Divine"
(James O. Coplien, Bell Labs)
Francesco Chicchiriccò (JIRA)
2012-12-03 15:31:59 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò updated COCOON3-105:
-------------------------------------------

Attachment: COCOON3-105.patch
Post by Thorsten Scherler (JIRA)
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.
- 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.
[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
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.
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
Francesco Chicchiriccò (JIRA)
2012-12-03 15:34:00 UTC
Permalink
[ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francesco Chicchiriccò updated COCOON3-105:
-------------------------------------------

Attachment: (was: COCOON3-105.patch)
Post by Thorsten Scherler (JIRA)
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, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
- 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.
[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
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.
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
Loading...