Hi all,
any reaction on this? Shall I just apply such huge patch without anyone
else's confirmation??!?
Regards.
On 03/12/2012 16:38, Francesco Chicchiriccò wrote:
Hi all,
I have finally elaborated a fix for COCOON3-105 and now I am able to
run more C3-based webapps in the same servlet container.
I have also added a comment explaining the way I have fixed the issue:
as you can see, it is a considerable change, so I'd like to get your
feedback before applying.
Please take a look and let me know.
Regards.
On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508800#comment-13508800
]
Francesco Chicchiriccò commented on COCOON3-105:
------------------------------------------------
Please evaluate the attached patch (COCOON3-105.patch).
The patch is quite pervasive and I've seen that it might also cause
some troubles when applying: if you find any .rej or .orig files
(after application), please remove.
This patch basically removes any reference to the blockcontext:/
protocol - as you can see there is no more dependency on
cocon-block-deployment.
The blockcontext:/ protocol has been replaced by a classpath:/
protocol implementation, working together with the JVM's jar:/ protocol.
I have also prepared a demo project for this [1]: after having "mvn
clean install" on the patched C3 source tree, just clone, switch to
branch COCOON3-105 and compile by running
mvn clean package
then launch via
mvn cargo:run
You will get an Apache Tomcat instance listening on 8888 containing
two distinct C3 webapps; access URLs are
http://localhost:8888/mywebapp/
http://localhost:8888/mywebapp2/mysite/
http://localhost:8888/mywebapp2/mysite2/
e.g. 3 distinct blocks across 2 distinct webapps.
Please note that this fix should also work for C2.2, as far as the
ClasspathURLStreamHandlerFactory class is provided - I've put this
class in cocoon-servlet but we can think to move it to
cocoon-servlet-service-impl, for example.
[1] https://github.com/ilgrosso/cocoon3EmptyProject
webapp fails if on the same servlet container is a c2.2.1 or other
c3 webapp running
-------------------------------------------------------------------------------------
Key: COCOON3-105
URL: https://issues.apache.org/jira/browse/COCOON3-105
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Assignee: Francesco Chicchiriccò
Priority: Blocker
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, COCOON3-105.patch,
COCOON3-105.patch, cocoon-block-deployment.patch,
cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
To reproduce:
- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype
where webapp depends on block one and webapp2 depends on block2.
My sample was:
[INFO] Reactor Summary:
[INFO]
[INFO] myparent .......................................... SUCCESS
[1.163s]
[INFO] myblock ........................................... SUCCESS
[3.611s]
[INFO] mywebapp .......................................... SUCCESS
[1.924s]
[INFO] myblock2 .......................................... SUCCESS
[1.498s]
[INFO] mywebapp2 ......................................... SUCCESS
[1.230s]
[INFO]
------------------------------------------------------------------------
Now take a tomcat (I used 6) and first deploy the mywebapp. You can
copy it before you start to webapp or if you have it enable deploy
it on a running instance. You should see the welcome page under
something like http://localhost:8080/mywebapp-1.0-SNAPSHOT/
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Now if you deploy the second webapp on a running instance it will
deploy without problem but requesting
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException:
Can't build sitemap from blockcontext:/myblock2/sitemap.xmap
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2'
deployed. The available blocks are
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at
org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection.java:56)
~[cocoon-block-deployment-1.2.1.jar:1.2.1]
at java.net.URL.openStream(URL.java:1010) ~[na:1.6.0_30]
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:65)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
... 46 common frames omitted
As you see the blockcontext from the 2nd app is the one from the
first EVEN if they are deployed as 2 different webapps!
Now stop the tomcat and start again.
Depending which app you request on a fresh stared tomcat that one
will work the other will present a blank page and the log will say
something like:
Caused by: java.lang.RuntimeException: There is no block 'myblock'
deployed. The available blocks are
{myblock2=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp2-1.0-SNAPSHOT/blocks/myblock2/}.
In this case I requested the 2nd first.
Originally I found out because we have a client that has some c3 and
a c2.2.1 app (not) running aside. So in case you create a 2.2.1
webapp from the archetype as described
http://cocoon.apache.org/2.2/1159_1_1.html and use it instead of the
c3 2nd webapp you will get similar results.
If you start first with the 1st c3 and then deploy the c2.2 on the
run then you can actually see both working ONLY if you first request
the c3 and then deploy and then see the c2. In case you do not
request the c3 prior it will not work once you requested the c2
(which maybe present interesting for the cause of the problem).
Now shutdown and start with both deployed the c2.2 always works and
the c3 not.
I see the problem for our client coming when we introduced
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
The main observation is that the c2 one seems to much more
presistence but that can come the way of invocation (on-demand vs.
startup). Anyway the blockcontext should never be shared between two
different servlets.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
