[C3] Group and artifact IDs (was: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI)
Hi Reinhard, Am 21.08.08 23:53, schrieb Reinhard Pötz: After having already discussed the details, let's make a formal decision about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3. […] Maven --- We use functional names for all artifacts: org.apache.cocoon.pipeline:cocoon-pipeline:3.0.0 org.apache.cocoon.sitemap:cocoon-sitemap:3.0.0 org.apache.cocoon.servlet:cocoon-servlet:3.0.0 org.apache.cocoon.controller:cocoon-controller:3.0.0 org.apache.cocoon.rest:cocoon-rest:3.0.0 org.apache.cocoon.stringtemplate:cocoon-stringtemplate:3.0.0 By using the functional name as part of the groupId, Cocoon 2.2 and Cocoon 3 can be used together without getting any problems with the dependency resolution mechanisms of Maven or Ivy. I just stumbled upon this again. Our group IDs look verbose and redundant at a first glance; from my experience it is rather unusual to use distinct group IDs for the individual projects. Would you mind elaborating a bit why it helps to have the artifact ID (functional name) as part of the group ID? Would the version number not be sufficient for the dependency resolution? TIA! Best regards, Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: PermGen memory leak in cocoon-jnet
Am 29.11.11 02:55, schrieb Andreas Hartmann: 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? The following patch avoids the memory leak, but I have the feeling that it has functional drawbacks, otherwise the code would already look like this :) Does anybody know how I can test if the class still fulfils its purpose? Maybe it's possible to provide a unit test? TIA! Index: src/main/java/org/apache/cocoon/jnet/URLStreamHandlerFactoryInstaller.java === --- src/main/java/org/apache/cocoon/jnet/URLStreamHandlerFactoryInstaller.java (revision 1208388) +++ src/main/java/org/apache/cocoon/jnet/URLStreamHandlerFactoryInstaller.java (working copy) @@ -28,13 +28,8 @@ public class URLStreamHandlerFactoryInstaller { public static void setURLStreamHandlerFactory(URLStreamHandlerFactory factory) throws Exception { -try { -// if we can set the factory, its the first! -URL.setURLStreamHandlerFactory(new ParentableURLStreamHandlerFactory(factory, null)); -} catch (Error err) { -ParentableURLStreamHandlerFactory currentFactory = getCurrentFactory(); -setCurrentFactory(new ParentableURLStreamHandlerFactory(factory, currentFactory)); -} +ParentableURLStreamHandlerFactory currentFactory = getCurrentFactory(); +setCurrentFactory(new ParentableURLStreamHandlerFactory(factory, currentFactory)); } -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
RE: PermGen memory leak in cocoon-jnet
Hi all, URL.setURLStreamHandlerFactory is singleton call which should only be used when you own the JVM. Calling it from C3 which is expected to play nicely with other servlets in the same container, it is a no-no. Jnet should be changed, for example by providing a createURL(String spec) factory method which calls the URL(protocol,host,port,file,handler) with the handler matching the custom protocol. Cheers, Alfred. -Original Message- From: Andreas Hartmann [mailto:andr...@apache.org] Sent: Mittwoch, 30. November 2011 14:10 To: dev@cocoon.apache.org Subject: Re: PermGen memory leak in cocoon-jnet Am 29.11.11 02:55, schrieb Andreas Hartmann: 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? The following patch avoids the memory leak, but I have the feeling that it has functional drawbacks, otherwise the code would already look like this :) Does anybody know how I can test if the class still fulfils its purpose? Maybe it's possible to provide a unit test? TIA! -- Andreas N��{^����zf��+�קu�h�\���ay�'~'^�ؚ����az�u�ǝ!ޞ�m�觵��y��r*bz{i���zz-��jw]zW�z�b�隊X���bjץ�8Z�L�