Re: [DISCUSS] Fix for COCOON3-105
On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote: Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto: On 14/01/2013 16:20, Thorsten Scherler wrote: [...] 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. 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/
Re: [DISCUSS] Fix for COCOON3-105
On 02/05/2013 04:10 PM, Thorsten Scherler wrote:
On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote:
Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto:
...
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
groupIdcom.mycompany/groupId
- artifactIdmysite2/artifactId
+ artifactIdmysite/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/
Re: [DISCUSS] Fix for COCOON3-105
On 05/02/2013 16:32, Thorsten Scherler wrote:
On 02/05/2013 04:10 PM, Thorsten Scherler wrote:
On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote:
Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto:
...
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
groupIdcom.mycompany/groupId
- artifactIdmysite2/artifactId
+ artifactIdmysite/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/
Re: [DISCUSS] Fix for COCOON3-105
Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto: On 14/01/2013 16:20, Thorsten Scherler wrote: [...] 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. 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/
Re: [DISCUSS] Fix for COCOON3-105
On 14/01/2013 16:20, Thorsten Scherler wrote: [...] 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. 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/
Re: [DISCUSS] Fix for COCOON3-105
On 12/20/2012 02:05 PM, Francesco Chicchiriccò wrote: On 20/12/2012 13:45, Leonardo Miceli wrote: Hello On 12/07/2012 01:33 PM, Francesco Chicchiriccò wrote: On 07/12/2012 13:09, Jos Snellings wrote: 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? 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/
Re: [DISCUSS] Fix for COCOON3-105
Hello On 12/07/2012 01:33 PM, Francesco Chicchiriccò wrote: On 07/12/2012 13:09, Jos Snellings wrote: 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? 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.
Re: [DISCUSS] Fix for COCOON3-105
On 20/12/2012 13:45, Leonardo Miceli wrote: Hello On 12/07/2012 01:33 PM, Francesco Chicchiriccò wrote: On 07/12/2012 13:09, Jos Snellings wrote: 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? 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/
Re: [DISCUSS] Fix for COCOON3-105
Hi all, any reaction on this? Shall I just apply such huge patch without anyone else's confirmation??!? Regards. On 03/12/2012 16:38, Francesco Chicchiriccò wrote: Hi all, I have finally elaborated a fix for COCOON3-105 and now I am able to run more C3-based webapps in the same servlet container. I have also added a comment explaining the way I have fixed the issue: as you can see, it is a considerable change, so I'd like to get your feedback before applying. Please take a look and let me know. Regards. On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 containing two distinct C3 webapps; access URLs are http://localhost:/mywebapp/ http://localhost:/mywebapp2/mysite/ http://localhost:/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:
RE: [DISCUSS] Fix for COCOON3-105
I might have time to check this weekend but I can't guarantee it. Robby -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Friday, December 07, 2012 12:50 PM To: dev@cocoon.apache.org Subject: Re: [DISCUSS] Fix for COCOON3-105 Hi all, any reaction on this? Shall I just apply such huge patch without anyone else's confirmation??!? Regards. On 03/12/2012 16:38, Francesco Chicchiriccò wrote: Hi all, I have finally elaborated a fix for COCOON3-105 and now I am able to run more C3-based webapps in the same servlet container. I have also added a comment explaining the way I have fixed the issue: as you can see, it is a considerable change, so I'd like to get your feedback before applying. Please take a look and let me know. Regards. On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian. jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1 3508800#comment-13508800 ] Francesco Chicchiriccò commented on COCOON3-105: Please evaluate the attached patch (COCOON3-105.patch). The patch is quite pervasive and I've seen that it might also cause some troubles when applying: if you find any .rej or .orig files (after application), please remove. This patch basically removes any reference to the blockcontext:/ protocol - as you can see there is no more dependency on cocon-block-deployment. The blockcontext:/ protocol has been replaced by a classpath:/ protocol implementation, working together with the JVM's jar:/ protocol. I have also prepared a demo project for this [1]: after having mvn clean install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and compile by running mvn clean package then launch via mvn cargo:run You will get an Apache Tomcat instance listening on containing two distinct C3 webapps; access URLs are http://localhost:/mywebapp/ http://localhost:/mywebapp2/mysite/ http://localhost:/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
Re: [DISCUSS] Fix for COCOON3-105
In shorthand: What are the implications then? Bottomline: - a block context is addressable within the sitemap load resource from another block context is possible via 'classpath'. The root of every block is available on the classpath? - different web applications relying on cocoon3 can deploy blocks with the same name they won't interfere with each other? Best, Jos On Fri, Dec 7, 2012 at 12:56 PM, Robby Pelssers robby.pelss...@nxp.comwrote: I might have time to check this weekend but I can't guarantee it. Robby -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Friday, December 07, 2012 12:50 PM To: dev@cocoon.apache.org Subject: Re: [DISCUSS] Fix for COCOON3-105 Hi all, any reaction on this? Shall I just apply such huge patch without anyone else's confirmation??!? Regards. On 03/12/2012 16:38, Francesco Chicchiriccò wrote: Hi all, I have finally elaborated a fix for COCOON3-105 and now I am able to run more C3-based webapps in the same servlet container. I have also added a comment explaining the way I have fixed the issue: as you can see, it is a considerable change, so I'd like to get your feedback before applying. Please take a look and let me know. Regards. On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian. jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1 3508800#comment-13508800 ] Francesco Chicchiriccò commented on COCOON3-105: Please evaluate the attached patch (COCOON3-105.patch). The patch is quite pervasive and I've seen that it might also cause some troubles when applying: if you find any .rej or .orig files (after application), please remove. This patch basically removes any reference to the blockcontext:/ protocol - as you can see there is no more dependency on cocon-block-deployment. The blockcontext:/ protocol has been replaced by a classpath:/ protocol implementation, working together with the JVM's jar:/ protocol. I have also prepared a demo project for this [1]: after having mvn clean install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and compile by running mvn clean package then launch via mvn cargo:run You will get an Apache Tomcat instance listening on containing two distinct C3 webapps; access URLs are http://localhost:/mywebapp/ http://localhost:/mywebapp2/mysite/ http://localhost:/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
Re: [DISCUSS] Fix for COCOON3-105
On 07/12/2012 13:09, Jos Snellings wrote:
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.
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?
Everything should be working in the same way.
- 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/
