[jira] [Reopened] (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Crossley reopened COCOON-2288: Need to also add its license file to the "legal" directory as is done for other dependencies. > Allow usage of SLF4J for traces > --- > > Key: COCOON-2288 > URL: https://issues.apache.org/jira/browse/COCOON-2288 > Project: Cocoon > Issue Type: New Feature > Components: * Cocoon Core >Reporter: Cédric Damioli > Fix For: 2.1.12-dev (Current SVN) > > Attachments: SLF4JLogger.java, Slf4jLoggerManager.java, > SLF4JLoggerManager.java > > > Attached are two classes allowing to use SLF4J as logging facade inside > Cocoon. -- 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
[jira] [Closed] (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cédric Damioli closed COCOON-2288. -- Resolution: Fixed > Allow usage of SLF4J for traces > --- > > Key: COCOON-2288 > URL: https://issues.apache.org/jira/browse/COCOON-2288 > Project: Cocoon > Issue Type: New Feature > Components: * Cocoon Core >Reporter: Cédric Damioli > Fix For: 2.1.12-dev (Current SVN) > > Attachments: SLF4JLogger.java, Slf4jLoggerManager.java, > SLF4JLoggerManager.java > > > Attached are two classes allowing to use SLF4J as logging facade inside > Cocoon. -- 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
[jira] [Commented] (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508934#comment-13508934 ] Cédric Damioli commented on COCOON-2288: My mistake. I was focused on splitting sources from libs and forgot to commit that one. Committed slf4j-api in revision 1416633 > Allow usage of SLF4J for traces > --- > > Key: COCOON-2288 > URL: https://issues.apache.org/jira/browse/COCOON-2288 > Project: Cocoon > Issue Type: New Feature > Components: * Cocoon Core >Reporter: Cédric Damioli > Fix For: 2.1.12-dev (Current SVN) > > Attachments: SLF4JLogger.java, Slf4jLoggerManager.java, > SLF4JLoggerManager.java > > > Attached are two classes allowing to use SLF4J as logging facade inside > Cocoon. -- 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
[DISCUSS] Fix for COCOON3-105
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 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: 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
[DISCUSS] Fix for COCOON3-105
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 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: 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/
[jira] [Updated] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated COCOON3-105:
---
Attachment: (was: COCOON3-105.patch)
> 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.
> 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 r
[jira] [Updated] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated COCOON3-105:
---
Attachment: COCOON3-105.patch
> 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
[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: 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(BlockContextU
[jira] [Updated] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò updated COCOON3-105:
---
Attachment: COCOON3-105.patch
> 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.
> 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
[jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> 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.
> 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
[jira] [Closed] (COCOON3-107) With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, integration tests fail
[ https://issues.apache.org/jira/browse/COCOON3-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò closed COCOON3-107. -- Resolution: Invalid This issue is generated by an incorrect fix for COCOON3-105 that I am about to revert. > With latest cocoon-block-deployment and cocoon-service-impl SNAPSHOTs, > integration tests fail > - > > Key: COCOON3-107 > URL: https://issues.apache.org/jira/browse/COCOON3-107 > Project: Cocoon 3 > Issue Type: Bug > Components: cocoon-sample-webapp, cocoon-servlet, cocoon-sitemap >Affects Versions: 3.0.0-beta-1 >Reporter: Francesco Chicchiriccò >Priority: Critical > Fix For: 3.0.0-beta-1 > > Attachments: BlockcontextInterpreter.java, > BlockcontextInterpreter.java > > > This is happening as a consequence of COCOON3-105, by upgrading > cocoon-servlet-service-impl to 1.3.2-SNAPSHOT and cocoon-block-deployment to > 1.2.2-SNAPSHOT > Basically, since there is no more an installed URLStreamHandlerFactory, every > "new URL()" should include an instance of BlockContextURLStreamHandler. > This makes every other URL loading (including XSLT sheets in a separate > block, like happening for cocoon-sample-webapp) unaware of "blockcontext://" > URLs. -- 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
[jira] [Reopened] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reopened COCOON3-105:
Assignee: Francesco Chicchiriccò
> 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.
> 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
