Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
On 27/11/2011 00:58, Thorsten Scherler wrote: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. In this way we would easily manage everything in one place - including Sonar, JIRA, Jenkins and Maven artifacts. Actually I really dislike that we have two different instance of jira for cocoon. IMO one is more then enough. So having one for our project and all our components would not force us to move them. Further in the end ALL our codebase (2.1 and 2.2 incl.) is our concern as project. We need to find time to apply patches not only for c3. For example I am ATM basing a big project on c3 but we have as well 2.2 and 2.1 based projects in maintenance so like me we have devs that are using cocoon in the different versions. We as project should concern about them. Of course, we would loose the separation among Cocoon own stuff and Cocoon stuff that can be used even when not using Cocoon: do you retain such distinction still necessary, these days? Actually cocoon spring configurator is a nice peace of standalone code and if we do not need to have deps on c3 modules we should not enforce that components can only be used in conjunction with c3. The less deps cocoon and any of its modules has the better. In general I am for svn cp and create a new version. Well, at the moment the components named above (but others are missing: cocoon-jnet, for example) are spread across different folders in svn repository, so an idea could be to define a subfolder of /trunk (say 'subprojects') and start svn cp-ing all of such components under /trunk/subprojects. Then we would need some INFRA tasks like as: * add (when needed) all of these as components in JIRA (under COCOON or COOON3?) * add to Sonar * add to Jenkins (including SNAPSHOT maven artifact deployment) * .. Can you prepare a vote, please? Hum, I am not sure whether this issue is mature for voting: I'd rather understand what exactly has to be put on vote: anyone else interested on this topic? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: PermGen memory leak in cocoon-jnet
On 29/11/2011 02:55, Andreas Hartmann wrote: Hi everyone, when undeploying a C3 app, I'm experiencing a PermGen memory leak due to cocoon-jnet. You find more general info on the subject at [1]. This is the reference chain: class java.net.URL - org.apache.cocoon.jnet.URLStreamHandlerFactoryInstaller$ParentableURLStreamHandlerFactory - org.apache.cocoon.jnet.URLStreamHandlerFactoryInstaller$ParentableURLStreamHandlerFactory - org.apache.catalina.loader.WebappClassLoader The problem is this line of code in URLStreamHandlerFactoryInstaller; commenting it out resolves the memory leak: URL.setURLStreamHandlerFactory(new ParentableURLStreamHandlerFactory(factory, null)); Here the static reference from java.net.URL to a Cocoon class is set. Does anyone know if and how the reference can be removed, or if we can achieve the same behaviour without registering the factory with java.net.URL? TIA for any hints! Hi Andreas, first of all, I don't know how to fix the issue you are pointing out :-) I just want to outline that cocoon-jnet [2] is just another example of Cocoon subproject that would need some maintenance, as currently discussing in thread [3]: are you interested in joining such conversation? Regards. [1] http://blogs.oracle.com/fkieviet/entry/how_to_fix_the_dreaded [2] https://svn.apache.org/repos/asf/cocoon/trunk/subprojects/cocoon-jnet/ [3] https://mail-archives.apache.org/mod_mbox/cocoon-dev/20.mbox/%3c4ed0fb57.3050...@apache.org%3E -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Created] (COCOON3-82) Allow Saxon to be used as a XSLT transformer
Allow Saxon to be used as a XSLT transformer Key: COCOON3-82 URL: https://issues.apache.org/jira/browse/COCOON3-82 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-beta-1 Reporter: Huib Verweij In order to use XSLT 2.0 features (and beyond) in a XSLT transform I need to be able to use Saxon as a transformer. In C2.2 this could be done. There is a way of defining the transformer to be used in the system settings: -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl. This might work, I am not sure, but then the choice of XSLT processor is gone - but that is perhaps not important? -- 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]
Am 27.11.11 00:58, schrieb Thorsten Scherler: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. IMO the current SVN structure is not really transparent. Trunk (2.2) and cocoon3/trunk are conflicting versions. Maybe the following would make sense? branches/ cocoon-2.2/ cocoon-3/ … subprojects/ cocoon-jnet … Of course this would imply that the subprojects have a well-defined API and functionality which is independent from any particular functionality in any of the Cocoon branches. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
