Re: Cocoon 2.2 classic webapp
Reinhard Pötz wrote: I've fixed this in trunk (hopefully without introducing any other incompatibilities). Now you can use the lastest snapshot dependencies: [...] Can you test it again please? It works perfectly and no longer depends on BlockDeploymentServletContextListener or cocoon-servlet-service-components. I used the artifact versions you suggested. It also works without dependency versions using a parent element with cocoon-core-modules version 6-SNAPSHOT. Thanks! -Hugh Sparks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Reinhard Pötz wrote:
Hugh Sparks wrote:
Many thanks to Reinhard Pötz!
To make this work with the current trunk, a few simple changes are
needed:
pom.xml: Add a dependency for cocoon-servlet-service-components
parent
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core-modules/artifactId
version6-SNAPSHOT/version
/parent
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core/artifactId
/dependency
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-template-impl/artifactId
/dependency
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-servlet-service-components/artifactId
/dependency
web.xml: Add a listener for BlockDeploymentServletContextListener
listener
descriptionDeclare a context listener that installs all
blocks./description
listener-classorg.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener/listener-class
/listener
I don't understand why these components should be required if they
aren't used, but this gets the webapp going without errors.
If you're right, this has to be fixed before the next release of Cocoon
2.2.
I've fixed this in trunk (hopefully without introducing any other
incompatibilities). Now you can use the lastest snapshot dependencies:
dependencies
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core/artifactId
version2.2.1-SNAPSHOT/version
/dependency
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-template-impl/artifactId
version1.2.0-SNAPSHOT/version
/dependency
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.4/version
scopeprovided/scope
/dependency
/dependencies
Can you test it again please?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Hugh Sparks wrote: Hugh Sparks wrote: Many thanks to Reinhard Pötz! I'll repeat the experiment again: First, I checked out the classic webapp from the svn and verified that it works perfectly. Next, I edited the pom so it looks like this: ( My maven repository is freshly charged from cocoon trunk 685741) snip I decided to try a totally fresh maven repository. So I deleted _everything_ in my .m2/repository directory Then I went to ...\cocoon22-classic-webapp and did mvn install jetty:run It worked perfectly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Nice archetype, I think is useful a maven archetype like this for the community. +1 :) In the last months, I worked hard with cocoon 2.2. I want share with community some mini blocks like: cocoon-2.2-hibernate cocoon-2.2-jackrabbit cocoon-2.2-custom-reader ... I think in a week, I can release these simple/sample blocks. Bye Alessandro Reinhard Pötz wrote: I've just committed a sample module for a 'Classic Cocoon 2.2 webapp' to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used without the Servlet-Service Framework or custom blocks. Both are great features but they are not needed in every case, e.g. if you want a simple migration for Cocoon 2.1 to 2.2 you might not want to introduce blocks and servlet services from the beginning. I wrote a blog entry[1] that provides some information how you can run the module. If this is useful for others too, it could be moved to the trunk and also become the base for a new Maven archetype. Have fun! [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624 begin:vcard fn:Alessandro Vincelli n:;Alessandro Vincelli url:http://www.alessandro.vincelli.name version:2.1 end:vcard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Reinhard Pötz wrote: I've just committed a sample module for a 'Classic Cocoon 2.2 webapp' to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used without the Servlet-Service Framework or custom blocks. Both are great features but they are not needed in every case, e.g. if you want a simple migration for Cocoon 2.1 to 2.2 you might not want to introduce blocks and servlet services from the beginning. I wrote a blog entry[1] that provides some information how you can run the module. If this is useful for others too, it could be moved to the trunk and also become the base for a new Maven archetype. Have fun! [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624 Thanks, Reinhard, this is very welcome. I've been a bit busy on other projects apart from cocoon for a while, but trying this one out moves rapidly up the TODO: list. Bye for now, Ken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Ken Starks wrote: Reinhard Pötz wrote: I've just committed a sample module for a 'Classic Cocoon 2.2 webapp' to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used without the Servlet-Service Framework or custom blocks. Both are great features but they are not needed in every case, e.g. if you want a simple migration for Cocoon 2.1 to 2.2 you might not want to introduce blocks and servlet services from the beginning. I wrote a blog entry[1] that provides some information how you can run the module. If this is useful for others too, it could be moved to the trunk and also become the base for a new Maven archetype. Have fun! [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624 Thanks, Reinhard, this is very welcome. I've been a bit busy on other projects apart from cocoon for a while, but trying this one out moves rapidly up the TODO: list. Bye for now, Ken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks again Reinhard. I managed to get this one to work first attempt. ( For the information of others: I used mvn install jetty:run and went to http://localhost:/welcome I got the welcome page, src was: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html head META http-equiv=Content-Type content=text/html; charset=ISO-8859-1 titleClassic Cocoon 2.2 Webapp : Welcome/title /head body h1 xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;Classic Cocoon 2.2 Webapp : Welcome/h1 If you are seeing this page, this minimal Cocoon 2.2 based web application is running correctly. br br br br br div id=footer div style=float: right;Wed Aug 13 19:38:14 BST 2008/div Apache Cocoon 2.2.0 /div /body ) /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Ken Starks wrote: Ken Starks wrote: Reinhard Pötz wrote: I've just committed a sample module for a 'Classic Cocoon 2.2 webapp' to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used without the Servlet-Service Framework or custom blocks. Both are great features but they are not needed in every case, e.g. if you want a simple migration for Cocoon 2.1 to 2.2 you might not want to introduce blocks and servlet services from the beginning. I wrote a blog entry[1] that provides some information how you can run the module. If this is useful for others too, it could be moved to the trunk and also become the base for a new Maven archetype. Have fun! [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624 Thanks, Reinhard, this is very welcome. I've been a bit busy on other projects apart from cocoon for a while, but trying this one out moves rapidly up the TODO: list. Bye for now, Ken. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks again Reinhard. I managed to get this one to work first attempt. snip It also worked when I copied the war file over to the Tomcat webapps directory. url: http://localhost/cocoon22-classic-webapp-1.0-SNAPSHOT/welcome (This is for my Tomcat, which is serving on port 80. others should insert their local servlet-container's port number) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Many thanks to Reinhard Pötz! To make this work with the current trunk, a few simple changes are needed: pom.xml: Add a dependency for cocoon-servlet-service-components parent groupIdorg.apache.cocoon/groupId artifactIdcocoon-core-modules/artifactId version6-SNAPSHOT/version /parent dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId /dependency dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-template-impl/artifactId /dependency dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-servlet-service-components/artifactId /dependency web.xml: Add a listener for BlockDeploymentServletContextListener listener descriptionDeclare a context listener that installs all blocks./description listener-classorg.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener/listener-class /listener I don't understand why these components should be required if they aren't used, but this gets the webapp going without errors. -Hugh Sparks, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Hugh Sparks wrote:
Many thanks to Reinhard Pötz!
To make this work with the current trunk, a few simple changes are needed:
pom.xml: Add a dependency for cocoon-servlet-service-components
parent
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core-modules/artifactId
version6-SNAPSHOT/version
/parent
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core/artifactId
/dependency
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-template-impl/artifactId
/dependency
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-servlet-service-components/artifactId
/dependency
web.xml: Add a listener for BlockDeploymentServletContextListener
listener
descriptionDeclare a context listener that installs all
blocks./description
listener-classorg.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener/listener-class
/listener
I don't understand why these components should be required if they
aren't used, but this gets the webapp going without errors.
If you're right, this has to be fixed before the next release of Cocoon 2.2.
Thanks for testing!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.2 classic webapp
Hugh Sparks wrote: Many thanks to Reinhard Pötz! To make this work with the current trunk, a few simple changes are needed: [...] Reinhard Pötz replies: If you're right, this has to be fixed before the next release of Cocoon 2.2. I'll repeat the experiment again: First, I checked out the classic webapp from the svn and verified that it works perfectly. Next, I edited the pom so it looks like this: ( My maven repository is freshly charged from cocoon trunk 685741) parent groupIdorg.apache.cocoon/groupId artifactIdcocoon-core-modules/artifactId version6-SNAPSHOT/version /parent dependencies dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId /dependency dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-template-impl/artifactId /dependency /dependencies ... jetty 6.1.7stuff... The result from mvn jetty:run was: java.lang.RuntimeException: Failed to obtain blockContexts Map. The most probable cause is that BlockDeploymentServletContextListener has not been executed. at org.apache.cocoon.spring.BlockPathPropertyPlaceholderConfigurer.processProperties (BlockPathPropertyPlaceholderConfigurer.java:50) at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory (PropertyResourceConfigurer.java:75) ... This lead me to try adding the BlockDeploymentServletContextListener to web.xml. When I did that, jetty:run produced: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.jnet.URLHandlerFactoryCollector' defined in URL [jar:file:/m2/repository/org/apache/cocoon/cocoon-jnet/ 1.1.0-SNAPSHOT/cocoon-jnet-1.1.0-SNAPSHOT.jar! /META-INF/cocoon/spring/cocoon-jnet-collector.xml]: Initialization of bean failed; nested exception is java.lang java.lang.NoClassDefFoundError: org/aspectj/lang/ProceedingJoinPoint ... At this point, I was dazed and confused, so I tried to figure out what brings in aspectj... After a little trial and error, I found that adding cocoon-servlet-service-components to the POM makes it all work. I liked the pom and web.xml a lot better the Reinhard wrote them, so perhaps these things can be undone? Thanks, -Hugh Sparks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
