[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[ https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175749#comment-13175749 ] Igor Malinin commented on COCOON3-85: - To reproduce: # git clone git://github.com/igorzep/cocoon-springification.git # cd cocoon-springification # mvn clean install # cd webapp # mvn jetty:run-web Long exception trace... Switch Spring version back to 3.0.7 in top-level pom - everything works as expected. The trace is: 2011-12-24 19:36:37.337:WARN::Failed startup of context JettyWebAppContext@56c492c8@56c492c8/,file:/W:/workspaces/agentler/clone/cocoon-springification/webapp/target/tmp/webapp/,W:\workspaces\agentler\clone\cocoon-springification\webapp\target\cocoon-springification-webapp-0.1-SNAPSHOT.war org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cocoon.blockdeployment.BlockResourcesHolder' defined in URL [jar:file:/W:/workspaces/agentler/clone/cocoon-springification/webapp/target/tmp/webapp/WEB-INF/lib/cocoon-block-deployment-1.1.0.jar!/META-INF/cocoon/spring/cocoon-blockdeployment-resourcesholder.xml]: Cannot resolve reference to bean 'javax.servlet.ServletContext' while setting bean property 'servletContext'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'javax.servlet.ServletContext': Post-processing of the FactoryBean's object failed; nested exception is java.lang.IllegalArgumentException: warning no match for this type name: org.apache.cocoon.sitemap.node.SerializeNode [Xlint:invalidAbsoluteTypeName] at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:464) at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:384) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111) at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:643) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:189) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:913) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:584) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:341) at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:102) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:164) at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:164) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55) at org.eclipse.jetty.server.handler.HandlerWrappe
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[ https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175747#comment-13175747 ] Igor Malinin commented on COCOON3-85: - Hmm... Probably this is because I am using AspectJ 1.6.6 (newer versions break Cocoon on Jetty7+ because of ServletContextFactoryBean is not synthetic). I'll try to get a stack trace for this and update my sample app so that you can reproduce it. > cocoon-spring-configurator doesn't work with Spring 3.1 > --- > > Key: COCOON3-85 > URL: https://issues.apache.org/jira/browse/COCOON3-85 > Project: Cocoon 3 > Issue Type: Bug > Components: cocoon-servlet >Affects Versions: 3.0.0-beta-1 >Reporter: Igor Malinin >Priority: Critical > Attachments: java.patch > > > There are several issues that prevent Cocoon 3 to work with Spring 3.1 > One issue I reported already in mailing list when Jetty7 + recent AspectJ was > failing, not the same issue is deeper and ServletContextFactoryBean doesn't > work at all with Spring 3.1. > Note that ServletContext is already in the Spring web-app context, although > with another name ('servletContext'). This is available starting from Spring > 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext' > solves problem partially, but still fails on XMLSitemapServlet initialization > (as it uses static field in ServletContextFactoryBean). > I will attach a patch (a little bit dirty, but not more than the current > implementation). But it assumes at least Spring 3.0. > As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have > as a dependency at leas 3.0 version of Spring Framework (for Java5 generics > etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1
[ https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175746#comment-13175746 ] Francesco Chicchiriccò commented on COCOON3-85: --- What is your use case? I've just tried to replace 3.0.7.RELEASE with 3.1.0.RELEASE in parent/pom.xml, then launched it.sh and all went fine. > cocoon-spring-configurator doesn't work with Spring 3.1 > --- > > Key: COCOON3-85 > URL: https://issues.apache.org/jira/browse/COCOON3-85 > Project: Cocoon 3 > Issue Type: Bug > Components: cocoon-servlet >Affects Versions: 3.0.0-beta-1 >Reporter: Igor Malinin >Priority: Critical > Attachments: java.patch > > > There are several issues that prevent Cocoon 3 to work with Spring 3.1 > One issue I reported already in mailing list when Jetty7 + recent AspectJ was > failing, not the same issue is deeper and ServletContextFactoryBean doesn't > work at all with Spring 3.1. > Note that ServletContext is already in the Spring web-app context, although > with another name ('servletContext'). This is available starting from Spring > 3.0. Making an alias 'javax.servlet.ServletContext' -> 'servletContext' > solves problem partially, but still fails on XMLSitemapServlet initialization > (as it uses static field in ServletContextFactoryBean). > I will attach a patch (a little bit dirty, but not more than the current > implementation). But it assumes at least Spring 3.0. > As Cocoon 3 project is moved to Java 1.6, it is probably also worth to have > as a dependency at leas 3.0 version of Spring Framework (for Java5 generics > etc.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
On 01/12/2011 21:47, Simone Tripodi wrote: > Hi all guys! > > Apologies for the lack of participations but looks like contributing in more > ASF communities requires a lot of time! :) > > My position are: > > * +1 on migrating old components - that's true that we could maintain them in > their proper branch, but at the same time they would need an update to be > more compliant with C3 - moreover, since we agreed on migrating to Java6, it > would worth started getting advantage from the new platform - that would > imply "subprojects" actualization. > > * +1 on restructuring the svn, I would like to restructure anyway the C3 > first: IMHO having all the modules in a flat structures starts being a little > confusing, even to me that I'm involved, I would suggest to move to a > different hierarchical structure, grouping modules by technology/extension > type/application type. > Moreover IMHO the 'optional' module should be split, it contains now a lot of > good reusable - more that at the begin - stuff that we could consider as a > collection of modules. > Of course, we have to pay attention to not overengineering. > I would suggest as well to open a Sandbox open to all ASF committers to > experiment new modules. > > My proposal is considering the two topics separately, I would like Francesco > lead the topic #1, I can prepare during the weekend a proposal on how to > restructure the SVN. Hi all, first of all, apologies for delay :-) Here it follows some results from my investigation of our current SVN repository ("from root to branches" someone would have said...) and also a proposal of mine for making things a bit easier to work with. I'll take the current structure at https://svn.apache.org/repos/asf/cocoon/ as reference and base URL. */branches/* Move current /trunk/ under here as BRANCH_2_2_X (similar to BRANCH_2_1_X and others, already present) so that any further activity on C2.2 can take place here. */cocoon3/* Move /cocoon3/trunk as /trunk/ (Simone restructuring as presented above will take place here) and /cocoon3/tags/** under /tags, possibly refactoring paths like as /cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/ to simpler /tags/cocoon-archetype-block-3.0.0-alpha-3/ */site/* Merge this with current /cocoon3/trunk/cocoon-docs */tags/* As said above for /cocoon3, move /cocoon3/tags/* here, possibly refactoring paths */trunk/* As said above for /cocoon3, move /cocoon3/trunk/* here. Then, copy current trunk/subprojects/ (i.e. /branches/BRANCH_2_2_X/subprojects/ after refactoring): cocoon-block-deployment/ cocoon-configuration/ cocoon-jnet/ cocoon-servlet-service/ cocoon-xml/ Next, copy some modules from current trunk/tools/ (i.e. /branches/BRANCH_2_2_X/tools/ after refactoring): cocoon-it-fw/ cocoon-maven-plugin/ cocoon-rcl/ Finally, copy from current trunk/blocks/cocoon-serializers/ (i.e. /branches/BRANCH_2_2_X/blocks/cocoon-serializers/ after refactoring): cocoon-serializers-charsets/ All modules involved with C3 should have now their places under /trunk/subprojects/ or /trunk/tools. If there is any module missing please let me know. We will need, of course, to adapt all pom.xml's for working in the new structure. WDYT? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/