Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]

2011-12-24 Thread Francesco Chicchiriccò 
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/

[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1

2011-12-24 Thread Commented 

[ 
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13175746#comment-13175746
 ] 

Francesco Chicchiriccò commented on COCOON3-85:
---

What is your use case? I've just tried to replace 
spring.version3.0.7.RELEASE/spring.version
with
spring.version3.1.0.RELEASE/spring.version

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

[jira] [Commented] (COCOON3-85) cocoon-spring-configurator doesn't work with Spring 3.1

2011-12-24 Thread Igor Malinin (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2011-12-24 Thread Igor Malinin (Commented) (JIRA) 

[ 
https://issues.apache.org/jira/browse/COCOON3-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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