[jira] [Assigned] (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned COCOON-1574: --- Assignee: (was: Ralph Goers) Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Environment: Operating System: Windows XP Platform: PC Reporter: Ronald Blaschke Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (COCOON-1329) [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war
[ https://issues.apache.org/jira/browse/COCOON-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned COCOON-1329: --- Assignee: (was: Ralph Goers) [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war --- Key: COCOON-1329 URL: https://issues.apache.org/jira/browse/COCOON-1329 Project: Cocoon Issue Type: Bug Components: Blocks: Portal Affects Versions: 2.1.5 Environment: Operating System: All Platform: Other Reporter: Michal Durdina Attachments: ASF.LICENSE.NOT.GRANTED--RELEASE_2_1_5_1.patch_2.txt, ASF.LICENSE.NOT.GRANTED--RELEASE_2_1_6.patch_2.diff Removal of checkEnvironment() in Cocoon.process() method. Needed for cocoon portal-to-portlet communication via RequestDispatcher.include() when portal.war and portlet.war are bundled into ear. Cocoon.jar is pulled from wars'/WEB- INF/lib to top ear level - as a result common ear classloader is used for its classes. Static class fields in cocoon.jar are influenced. Critical: static field 'environmentStack'. Two use cases: A.) WORKING: portal.war and portlet.war use TWO classloaders for cocoon.jar - every war has its own cocoon.jar in WEB-INF/lib - static class fields are instantiated in each classloader - every war sees its own instance of static field B.) NOT WORKING: portal.war and portlet.war use ONE classloader for cocoon.jar - every war uses cocoon.jar from ear - static class fields are instantiated only ONCE in ear classloader - all war sees same instance of static field This patch fixes getting/setting PortalServiceInfo from/to session. When portlet constructs its url's, it calls portal service DefaultLinkService. DefaultLinkService tries to get PortalServiceInfo from session and session is retrieved from Environment object that is currently at the top of environmentStack. Case A: Calling sequence of portal processing: portal.war#Cocoon.process() - portletInfo - portal.session // cl1, cl2 stands for classloader1, classloader2 cl1.envStack.top:=portal.session portlet.war#Cocoon.process() - cl2.envStack.top:=portlet.session portal.war#DefaultLinkService.getInfo() - session := cl1.envStack.top portletInfo - session(portal.session) // portletInfo != NULL portal.war#DefaultLinkService.getInfo() - portlet.war#Cocoon.process() - portal.war#Cocoon.process() - Case B: Calling sequence of portal processing: portal.war#Cocoon.process() - portletInfo - portal.session // cl1 stands for common classloader cl1.envStack.top:=portal.session portlet.war#Cocoon.process() - cl1.envStack.top:=portlet.session portal.war#DefaultLinkService.getInfo() - session := cl1.envStack.top portletInfo - session(portlet.session) // NPE: portletInfo == NULL portal.war#DefaultLinkService.getInfo() - portlet.war#Cocoon.process() - portal.war#Cocoon.process() - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] Commented: (COCOON-2288) Allow usage of SLF4J for traces
[ https://issues.apache.org/jira/browse/COCOON-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853992#action_12853992 ] Ralph Goers commented on COCOON-2288: - Not that there is anything wrong with your code, but it does seem a bit strange to have a logging facade - the Avalon Logger interface - call another facade - SLF4J. However, if you want to use Logback as your implementation that is the only way that is supported. SLF4J really isn't need to allow the Avalon Logger to bridge to Log4j, or java.util.logging. Allow usage of SLF4J for traces --- Key: COCOON-2288 URL: https://issues.apache.org/jira/browse/COCOON-2288 Project: Cocoon Issue Type: New Feature Components: * Cocoon Core Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: SLF4JLogger.java, SLF4JLoggerManager.java Attached are two classes allowing to use SLF4J as logging facade inside Cocoon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] Simone Tripodi as new Cocoon committer
On Dec 13, 2009, at 5:58 AM, Reinhard Pötz wrote: I propose Simone Tripodi as a new Cocoon committer and PMC member. Simone has been participating on our mailing lists since Sept 2008. Recently he provided an extensive patch that adds XInclude support to Cocoon 3. Additionally he provided 6 other patches. That shows that his interest in Cocoon is longer-term which he also confirmed at some chats that we both had. This vote ends one week from today, i.e. midnight UTC on Sunday 2009-12-20 So please cast your votes. +1 Ralph
Re: XPathXMLFileModule differences
It has been quite a while since I last worked on Cocoon, but since I
wrote XPathXMLFileModule I suppose I am best qualified to answer the
question.
XPathXMLFileModule is a replacement for XMLFileModule but it is not
completely compatible - which is why it is a new module and not just
an upgraded version of the old one. The differences were itemized in https://issues.apache.org/jira/browse/COCOON-1574
(see my comment on Dec 27, 2007)
On Aug 27, 2009, at 6:09 PM, Tim Williams wrote:
Is the new XPathXMLFileModule not a drop-in replacement for the
XMLFileModule? I'm wondering if we may have been depending on some
[?undocumented?] lazy-loading behavior of the old one or something.
In the xconf file I have:
component-instance
class=org.apache.cocoon.components.modules.input.XPathXMLFileModule
logger=core.modules.mapper.link name=linkmap
/component-instance
Leading to complaints of the absence of a src attribute. Our file
src aren't defined in the xconf file, but rather in the xmap
themselves, e.g.
input-module name=linkmap
file src={src} reloadable=true /
/input-module
It seems that the old version doesn't assume the file element exists
in the configure method:
Configuration[] files = config.getChildren(file);
for (int i = 0; i files.length; i++) {
but the new one does...
Configuration fileConfig = config.getChild(file);
this.src = fileConfig.getAttribute(src);
I admit that I've been away from forrest for some time so perhaps
there's something I'm missing here? Any pointers appreciated...
Thanks,
--tim
Re: Cocoon and Sling
On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote: dynnamitt wrote: Thanks man, I didn't know about that Phone-home feat. I did not however see GPL as an issue since the JVM(7) itself soon becomes a member. Does this mean that all apache apps will be stuck in JVM6 land ?? The GPL is imposed freedom, in that it states that any derived works of a GPL'ed product should also be GPL licensed itself, and thus that its source code should be distributed with the product. When your product (or Cocoon for that matter) uses classes from XMLCalabash, it becomes a derived product and thus must be GPL'ed. This is why any GPL library is a big no-no at Apache, since the Apache license is much more liberal and allows proprietary usage. The case of the JVM is different, because a Java application is not a derived work of the JVM, and only relies on the Java specification and the .class file format. You can then run your program on any virtual machine that understands this class file format. And by the way, Apache has an Apache-licensed virtual machine: http://harmony.apache.org/ Actually, this isn't quite accurate. Java applications are derivitive works (by the GPL definition) of the Java Library. However, OpenJDK uses GPL with the classpath exception for the library. The classpath exception is similar to the LGPL in that it says that your derived work can be under a different license. See http://freejdk.org/faqs/openjdk_license.html . Ralph
Re: Cocoon and Sling
I think it makes sense to evolve Cocoon to have a central portion of it revolve around pipeline processing and various ways of doing it. It would make sense to just come to one place rather than to have to go to two. On Apr 7, 2009, at 3:32 AM, Juan José Vázquez Delgado wrote: Hi all, As discussed in a previous thread [1], some people think it would be a good idea to take advantage of Cocoon´s pipelining and Sling request processing capabilities working together. We (Sling team) have implemented a first approach to this cooperation using Cocoon 3 pipeline engine [2] and the W3C XProc recomendation [3] in order to specify the pipelines to be performed. At least in the beginning, the Cocoon sitemap concept has been discarded because of quite overlapping between this one and Sling resource resolution. The code is available here [4] and details about how it works here [5]. From now on, I wonder whether Sling is the right place to keep on implementing W3C XProc or it´s Cocoon instead. Is this stuff interesting to Cocoon community and team?. Regards, Juanjo. [1] http://markmail.org/message/owefsfj4eqbc4ifq#query:OSGi %20integration [2] http://cocoon.apache.org//3.0/ [3] http://www.w3.org/TR/xproc/ [4] http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc/ [5] http://cwiki.apache.org/confluence/display/SLINGxSITE/XSLT+Processing+Pipeline
Fwd: Proposal: Commons SAX
Just in case you didn't see it, Jukka has set up a project at https://svn.apache.org/repos/asf/commons/sandbox/xml . Ralph Begin forwarded message: From: Henri Yandell flame...@gmail.com Date: February 5, 2009 10:27:51 PM PST To: Commons Developers List d...@commons.apache.org Subject: Re: Proposal: Commons SAX Reply-To: Commons Developers List d...@commons.apache.org On Wed, Dec 31, 2008 at 1:25 PM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Dec 31, 2008 at 8:55 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, Until we come up with consensus on where (Commons, Xerces or Cocoon) we should place this proposed library, I'd like to start putting some bits together in the Commons Sandbox. The Commons web page defines the Sandbox as a place to try out new ideas and prepare for inclusion into the Commons portion of the project [*] or into another Apache project, which is exactly what I'm planning to do. [*] Is this wording a leftover from Jakarta days? snip/ No, thats right. You can start in the Sandbox, consensus would be needed if you propose addition to Proper (there are no releases out of the Sandbox, so at some point you'd need to find the code a better home). Additionally, any committers at Tika or Cocoon who want commit access to this just has to pipe up and they'll be added to the sandbox karma. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New Spring Maintenance policy
First, let me say that I don't think the Spring policy is going to end up being as bad as it was made out to be at first glance, although that may just be wishful thinking. In any case, I think it is extremely premature to talk about forking the code. I think if you were to put yourself in the position where you were a happy employee of SpringSource looking to insure that your company stays healthy into the future, you would find it difficult to support the code being forked into the ASF. I certainly know I would. Although you'd probably like to think that what you do at the ASF is completely independent of your employer it is never really quite that simple. Reinhard Pötz wrote: Ralph Goers wrote: Thorsten Scherler wrote: On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote: Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? How people feel to create a spring fork here on the ASF and we can make sure that we will not have this problem in the future? You do realize that some ASF board members are employed by SpringSource, right? Should this have any influence on our decisions?
Re: New Spring Maintenance policy
Thorsten Scherler wrote: On Wed, 2008-09-24 at 09:10 -0600, Antonio Gallardo wrote: Hi, There is a worst case scenario now: What if they don't collect enough money from subscriptions and do the next step: remove the 3 months window or worse go full closed source? How people feel to create a spring fork here on the ASF and we can make sure that we will not have this problem in the future? You do realize that some ASF board members are employed by SpringSource, right? Ralph
Re: ApacheCon US
I will be there arriving on Sunday and leaving Saturday morning. I prefer not to share a room. Ralph Joerg Heinicke wrote: Hey guys, I'm considering to go to New Orleans. I justed wanted to ask who is planning to go as well and if anybody wants to share a room. Cheers, Joerg
Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI
+1 Reinhard Pötz wrote: After having already discussed the details, let's make a formal decision about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3. Versioning --- Cocoon 3 will follow the alpha/beta/rc release scheme (like Mozilla, Maven, Apache Commons, etc.). The first release will be 3.0-alpha-1. This will be a clear marker that is already visible when you add Cocoon as a dependency to your build or download the artifacts manually. Additionally all release artifacts will contain a warning message and an explanation what alpha means. SVN --- In order to make the life easier for people who use git-svn, I propose to use the standard SVN directory structure: http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk http://svn.apache.org/repos/asf/cocoon/cocoon3/tags 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. JAVA NAMESPACES --- Coocon 3 will use the org.apache.cocoon namespace. The sub-packages are reserved for functional names: org.apache.cocoon.pipeline org.apache.cocoon.sitemap org.apache.cocoon.servlet org.apache.cocoon.controller org.apache.cocoon.rest org.apache.cocoon.stringtemplate XML NAMESPACES --- Corona currently uses three different namespaces in XML documents: http://apache.org/cocoon/corona/sitemap http://apache.org/cocoon/corona/servlet http://apache.org/cocoon/corona/controller These namespaces are without a version number. Since I don't see how version numbers could help, I propose http://apache.org/cocoon/sitemap http://apache.org/cocoon/servlet http://apache.org/cocoon/controller Issue tracking --- I propose the creation of a COCOON3 Jira project so that Cocoon 2.x and Cocoon 3 issues don't get mixed up. CI --- Apache Infrastructure offers a managed Hudson instance. I propose to setup a Cocoon 3 project there. This majority vote stays open for 72 hours. Here is my +1.
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Sylvain Wallez wrote: By chronic disease, I was referring to Maven. And it's not specific to Cocoon, but to many other projects. Maven has brought one new brillant idea to the Java world, which is artifact repositories (note though that Linux repositories have existed for a very long time). But using Maven requires to adhere to the whole thing: repository management, which is good, but also a declarative under-documented build system. And Maven is also self-updating, which is a nice idea on paper but means the buid is not repeatable since you don't know what is used to build your system. Wow. I guess you don't like Maven. There are other alternatives to your complaints - like becoming a committer there and fixing them. Using Ant + Ivy has all the downfalls of GNU Make. Instead of one undocumented (not sure where you get that from) build system you end up with every build system being different and usually, mostly undocumented. As for the self-updating, dependency management allows you to have complete control over the artifacts you wish to use. My contribution to Maven has to continue to make that aspect better. Ralph
Re: [summary][vote] David Legg as new Cocoon committer
David Legg wrote: Once again, I'd like to thank the community for accepting me as a Cocoon committer. Finally, it is a good tradition that a new committer introduces himself on this list. I'm an English web developer, married with a child and working in Bracknell, England. I've been lurking around Cocoon for what seems like forever (read 2000). Back then SoC (Separation of Concerns), XML and XSLT were all shiny and new. I started my career back in 1984 writing 8086 assembler for a chess games company (oh yes! non of that 8-bit rubbish for me!). I even remember wondering if I should download Minix or something called Linux from some student upstart called Linus Torvalds ;-) The best thing I learnt from these early days was a healthy respect for designing memory efficient software. Goodness, gracious - that means you either started writing code in the crib or you are almost as old as me! Gradually and inevitably I moved over from writing system software and firmware to this new fangled thing called the web. This is where I fell in love with Java, Tomcat and JSP programming. You fell in love with JSPs? I have no idea what to say to that! My current interests lie in the semantic web and the world of triplestores, inference engines and RDF and how to do something useful with it all. You can be sure I'll be trying to glue it together with Cocoon. It's a privilege to be a part of this project. David Legg Welcome, David! Ralph
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Reinhard Pötz wrote: . Versioning --- For Cocoon 2 there have been proposals that all odd versions are development/alpha versions and all even versions are stable releases. I like this idea and propose that we follow this versioning schema in Cocoon 3: All 3.0.x releases are marked as development versions and we clearly explain this on the website and the READMEs of all artifacts. When we believe that the community and the technology are stable, we do a 3.1.0 release. I think this is less confusing than appending alpha, beta or milestone postfixes. +1 SVN --- I'm not sure about the new location in SVN. One option I can think of is http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk, the other is http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3 I slightly prefer http://svn.apache.org/repos/asf/cocoon/cocoon3-trunk. Why wouldn't you use http://svn.apache.org/repos/asf/cocoon/branches/cocoon-3.0.x? Then create 3.1.x when it is time for that. Presumably you will create a 3.2.x shortly after that so you can do bug fixes only on 3.1.x and new development on 3.2.x. If not, then I'm not sure what the point of the numbering scheme is. I'm OK with the rest of the proposal.
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. In the Maven issue (http://jira.codehaus.org/browse/MNG-624) the suggestion was made to use a variable. I'm not a big fan of that if it requires the variable always be set via -D or in the users settings.xml. Too much room to get it wrong. Using the version in the pom at the relative path you are sure to always get it right. The way my patch is right now if you specified MavenParentVersion as the version and it couldn't find the parent pom an exception would get thrown more or less as if a version wasn't specified. I suppose instead of throwing the exception it could try to find the pom some other way, but what? I have a feeling that if the way Cocoon's blocks parent pom was changed than what I'm suggesting would be easy. If the parent pom was in cocoon-blocks-parent instead of being the aggregation pom this would be a lot easier to deal with as you would only need the Cocoon parent project and the block parent project to create your block. Ralph
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Carsten Ziegeler wrote: Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. I'm not sure if there is an existing way of doing that. Even if there is, I'm not sure if that is a great idea. What if what is in your local repo is really old? Ralph
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. I'm not sure if there is an existing way of doing that. Even if there is, I'm not sure if that is a great idea. What if what is in your local repo is really old? I thought about this some more. How about if a) to enable this feature you put a variable as the version, b) the variable is replaced by its definition c) if it isn't defined then go to the relativePath and get the version from there, c) if this fails throw an exception. I believe this won't cause any problems since variables aren't currently supported. It is also what people have asked for in the Jira issue. Ralph
Re: [vote] Cocoon 3.0
+1 Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. Here is my +1
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: reinhard Date: Tue Aug 5 12:42:45 2008 New Revision: 682901 URL: http://svn.apache.org/viewvc?rev=682901view=rev Log: back in snapshot mode Modified: cocoon/trunk/tools/pom.xml Modified: cocoon/trunk/tools/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=682901r1=682900r2=682901view=diff == --- cocoon/trunk/tools/pom.xml (original) +++ cocoon/trunk/tools/pom.xml Tue Aug 5 12:42:45 2008 @@ -26,7 +26,7 @@ parent groupIdorg.apache.cocoon/groupId artifactIdcocoon/artifactId -version7/version +version5-SNAPSHOT/version relativePath../parent/relativePath Development version is lower than released one. Is it intended? yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Does anybody know if it can cause problems if the development version number isn't increased after a release? I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. Ralph
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
It uses the relative path so you will need the parent also. Carsten Ziegeler wrote: Ralph Goers wrote I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. And how does this work, if you just check out a single module instead of the whole tree? Carsten
Re: [vote] Java 1.5 as minimal requirement for trunk
+1 Grzegorz Kossakowski wrote: Hello, As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are more and more problems with keeping Java 1.4 compatibility in trunk. After a while it turned out that everybody agrees on the need for dropping Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal required version seems to be the best solution. In order to do that, we need a formal vote that I'm calling now. Please cast your votes: here's my +1 The vote will stay open until 12:00 UTC, 08.05.2008. [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/78439 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/78449
Re: A new name for Corona (take 2)
Doing a quick Google I didn't find anything relevant on Merenque. For Chasse I found http://www.atomicmpc.com.au/download/chasse.aspx and http://www.chasseconsulting.com/. The first is some sort of shareware/freeware hunting game for Windows and the second is a sales consulting firm. I couldn't locate the website of the author of the game, just various places it could be downloaded. Personally, I don't think either of these names would be a problem and would be happy with either one. I kind of like Merengue. It makes me think of Lemon Meringue Pie :-) . Meringue is also light and airly, sort of like a Cocoon. Did you notice that when you typed in Merenque in wikipedia it changed the spelling to Merengue? I didn't find anything relevant under that spelling on Google or TESS either. dictionary.com doesn't have a listing for Merenque but does for Merengue so I suspect that Merenque is an improper spelling in English. Of course, that isn't necessarily a problem. Ralph Reinhard Pötz wrote: Ralph Goers wrote: Reinhard Pötz wrote: Corona currently consists of 4 functional modules: cocoon-corona-pipeline, cocoon-corona-sitemap, cocoon-corona-controller and cocoon-corona-servlet. Using functional names isn't an appropriate solution for our problem. This would lead to a lot of confusion because we would get names that are already used (cocoon-pipeline, cocoon-sitemap). I'm really tired of this. What's next? 1) Just use Corona. If Eclipse complains we will be forced to rename the project to something else. Then you will get to do this all again, but it will be worse since artifacts will probably have been released and people will wonder where the project went. 2) Dream up a new name. a) Find a descriptive name along the lines of what Henri suggested - i.e. one or two words that describe what the purpose of the subproject is. b) Choose another codename despite Henri's suggestion. Use the link to TESS to determine whether it is available to use. Bertrand suggested one (Weedle). It doesn't show up at TESS and it's use on Google seems to revolve completely around Pokemon. A couple of other names were also suggested that I haven't checked. As I said before, I don't see any chance for a descriptive name that doesn't (partly) collide with something already existing in the Cocoon world. Weedle sounds (and looks) cute but TBH I'm not happy with its Pokemon origin. So let's find some more suggestions: Cocoon Chasse ~ Chasse or chassé is a dance step used in many dances in many variants, all of them being triple-step patterns of gliding character, steps going basically step-together-step (see http://en.wikipedia.org/wiki/Chasse) I really like the analogy to our concepts of pipelines: Pipeline ... Chasse Component .. Step Chasse is also used in many dances. In analogy this is also one of the goals of Corona that was designed to support different objects that are streamed (SAX events, STaX events, etc.). TESS doesn't show any usuage of Chasse in the context of software or electronics. Cocoon Merenque ~~~ Merengue is a type of lively, joyful music and dance that comes from the Dominican Republic[1]. It is popular in the Dominican Republic, and all over Latin America. Merengue means whipped egg whites and sugar in Spanish, similar to the English word meringue. It is unclear as to why this name became the name of the music of the Dominican Republic. But, perhaps, It can trace its meaning from the movement on the dance floor that could remind one of an egg beater in action. (http://en.wikipedia.org/wiki/Merenque) Again, I like the possible analogy of a pipeline and a dance. TESS doesn't show any usage of Merenque. Both names sound good to me as German speaker and I don't know of any irritating connotation. What do people who speak other languages think about it? My personal preference is Chasse because it slightly sounds better to me, is shorter and starts with a C.
Re: A new name for Corona (take 2)
Reinhard Pötz wrote: Ralph Goers wrote: Reinhard Pötz wrote: Let's summarize the proposed names (alphabetical order): Cocoon Chasse Cocoon Merenque Cocoon Morus Cocoon Weedle Could others please check these names too? Any general comments? Any other suggestions? I would agree except to suggest that perhaps the second should be Cocoon Merengue. I would also suggest Cocoon Meringue and it doesn't appear to have any significant conflicts that I could find. I would be fine with Cocoon Meringue too (although I slightly prefer the idea of using the name of a dance). Let's add it to the list! I was looking at pipeline in wikipedia and found http://www.reference.com/browse/wiki/Pipeline_%28software%29. I guess I shouldn't have been too surprised to see Cocoon right in the middle of the page. But it got me wondering. If what you are building is really going to be the heart or kernel of Cocoon then picking a codename may not do it justice. I've never really liked the word pipeline because I tend to think of surfing when I hear it. That isn't altogether bad I suppose, but it isn't altogether accurate either. I tend to think of what Cocoon does more as a pipetree rather than a pipeline since it isn't strictly a linear process and many branches can come into play. I'm not suggesting that that is a good name, but something more descriptive where the Cocoon implementation would be the classic example might have more significance in the long run. Of course, I suppose with our many attempts at a new Cocoon, Cocoon PipeDream might also be an appropriate name! ;-) Ralph
Re: [vote] David Legg as new Cocoon committer
+1 Grzegorz Kossakowski wrote: Dear community, I would like to propose David Legg as a new Cocoon committer and PMC Member. David is around Cocoon community since 2005 and lately become more active. He provided nice patche migrating us to Maven Archetype 2.0 plug-in and paid lots of attention to correcting our documentation. Moreover, he is active on user's mailing list helping other Cocoonerns with his accurate answers. He has a good open source and Cocoon's community understanding therefore makes him a perfect candidate for becoming Cocoon committer. I hope that this nomination will help David will improving our documentation even more. :-) Please cast your votes: here's mine +1
Re: A new name for Corona (take 2)
Vadim Gritsenko wrote: On Aug 4, 2008, at 3:49 AM, Ralph Goers wrote: I've never really liked the word pipeline because I tend to think of surfing when I hear it. That isn't altogether bad I suppose, but it isn't altogether accurate either. I tend to think of what Cocoon does more as a pipetree rather than a pipeline since it isn't strictly a linear process and many branches can come into play. I'm not suggesting that that is a good name, but something more descriptive where the Cocoon implementation would be the classic example might have more significance in the long run. Cocoon Tubes? Connect series of tubes and you get a pipeline! :-) Vadim Totally Tubular! http://www.inthe80s.com/glossary.shtml Ralph
[Fwd: Re: project names]
I received two responses from legal-internal regarding choosing a name. Both are below. To summarize, Sam doesn't state an opinion one way or the other on the name, just the basis for choosing one. Henri recommends against both Corona and Silk and would prefer that the name for subprojects as this be based on their function rather than a codename. For example, he would prefer something like Apache Cocoon Pipeline - which is more or less what we've been doing for blocks. Ralph Original Message Subject:Re: project names Date: Sat, 2 Aug 2008 09:20:15 -0400 From: Sam Ruby [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Most of the expertise in name-choosing is in the incubator. My understanding is that trademark law is based on the notion of likelihood of confusion, a standard that does not easily enable binary and final determinations short of litigation. TESS http://tess2.uspto.gov/bin/gate.exe?f=tessstate=879qc0.1.1 may be used to search for registered trademarks. - Sam Ruby On Sat, Aug 2, 2008 at 9:10 AM, Ralph Goers [EMAIL PROTECTED] wrote: Any advice on this? Ralph Goers wrote: The Cocoon community is in the process of creating a sub-project. We are having trouble coming up with a name that isn't already in use somewhere. The preferred name is Apache Cocoon Corona. However, Eclipse already has a Corona project. An alternative name is Apache Cocoon Silk. In this case Borland has products named Silk Test and Silk Performer. It doesn't appear to have a trademark on Silk yet I am aware that Silk is commonly used to refer to this group of products. What basis should the PMC use when choosing a name? It has basically been proposed that we just go ahead and use one under the assumption that no one will complain. FWIW, I have my opinion on this but am purposely not stating it here. Ralph - Sam Ruby Original Message Subject:Re: project names Date: Sat, 2 Aug 2008 07:41:18 -0700 From: Henri Yandell [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] I would consider both of these bad names. Silk has come up before in the Incubator and we chose not to use it (or maybe it was in Commons). Corona hasn't, but I think we should avoid any confusion with Eclipse. Personally I think you shouldn't have too many codenames. ie) it should be: Apache Cocoon Configuration Editor Apache Cocoon Magic Server etc. We get a bit silly with all the project names we seek to have. You only need the codename when you want it to live separately from Cocoon. Hen
Re: [Fwd: Re: project names]
Reinhard Pötz wrote: Corona currently consists of 4 functional modules: cocoon-corona-pipeline, cocoon-corona-sitemap, cocoon-corona-controller and cocoon-corona-servlet. Using functional names isn't an appropriate solution for our problem. This would lead to a lot of confusion because we would get names that are already used (cocoon-pipeline, cocoon-sitemap). I'm really tired of this. What's next? 1) Just use Corona. If Eclipse complains we will be forced to rename the project to something else. Then you will get to do this all again, but it will be worse since artifacts will probably have been released and people will wonder where the project went. 2) Dream up a new name. a) Find a descriptive name along the lines of what Henri suggested - i.e. one or two words that describe what the purpose of the subproject is. b) Choose another codename despite Henri's suggestion. Use the link to TESS to determine whether it is available to use. Bertrand suggested one (Weedle). It doesn't show up at TESS and it's use on Google seems to revolve completely around Pokemon. A couple of other names were also suggested that I haven't checked. Ralph
Re: Find a new name for Corona
Reinhard Pötz wrote: Borland hasn't trademarked silk but only some variants of it. See http://tinyurl.com/5bkw9d Silk was trademarked by a company called mentis: http://tess2.uspto.gov/bin/showfield?f=docstate=pgshps.20.117 The name that we would use is Cocoon Silk. So I tend to think that it isn't a problem. WDOT? Trademark or not, when people in software talk about Silk these products are what they mean. Using a name that is already highly branded would be a mistake. Maybe most of you are too young to get this but what would you think of a project named Apache SideKick? If it wasn't a Personal Information Manager people would be confused. If it was people would be even more confused. (If you don't know what SideKick was see http://en.wikipedia.org/wiki/SideKick). The point is, people would expect Cocoon Silk to be some sort of performance measurement tool, probably with the expectation that it hooks into Silk Test or Silk Performer somehow. (Which actually isn't a bad idea). Ralph
Re: Find a new name for Corona
Reinhard Pötz wrote: What would be the options that we vote on? a) keep the name Apache Cocoon Corona b) rename to Apache Cocoon Silk c) we need to find some other name Any other options? I sent a message to legal internal to get their opinion on options a and b. I suggest waiting for an answer. Ralph
Re: Find a new name for Corona
Sorry, I didn't do reply-all. I usually just do reply on all my Apache email. Reinhard Pötz wrote: Ralph Goers wrote: Reinhard Pötz wrote: What would be the options that we vote on? a) keep the name Apache Cocoon Corona b) rename to Apache Cocoon Silk c) we need to find some other name Any other options? I sent a message to legal internal to get their opinion on options a and b. I suggest waiting for an answer. Any reason not to cc dev@ or at least [EMAIL PROTECTED]
Re: Find a new name for Corona
Thorsten Scherler wrote: Just to say another name: ;) Apache Kokon which is cocoon in German. jeje this one is for Antonio: Apache Capullo which is cocoon in Spanish (but in Spain it has a slightly double meaning). salu2 Should I ask? I actually like both those names - depending on the secondary meaning.
Re: Find a new name for Corona
Silk is the shorthand name for SilkTest and SilkPerformer. http://www.borland.com/us/products/silk/index.html. Carsten Ziegeler wrote: Reinhard Pötz wrote: . Apache Cocoon Fiber . Apache Cocoon Silk . Apache Fiber . Apache Silk Any other suggestions? I agree with the others that we should leave Cocoon in the name. We have a very strong brand which we should use. I don't like Fiber - it reminds me of the German word (Fieber) for fever - and I can imagine many lame jokes on that one. :) Between the original spelling Fibre and Silk I prefer Silk. So +1 for Cocoon Silk. Carsten
Re: [vote] Steven Dolg as committer
+1 Ralph Reinhard Pötz wrote: Dear community, it's a great honor for me to propose Steven Dolg as a committer. In February Steven, Grzegorz and I invested three days in refactoring Cocoon so that we get a clean Java Pipeline API and a comprehensible sitemap/environment handling implementation of Cocoon. Unfortunately that was more difficult than we had expected. When I met Steven the week after those three days he came to me and said that he wanted to show me something. This something was a first prototype of what we call corona-pipeline (a standalone Java API) and corona-sitemap today. This was very encouraging and his work finally convinced me that a rewrite is an achievable goal. Without Steven we wouldn't have a soon to be released version of a complete rewrite of Cocoon which has thanks to a simple Java API a lot of potential to increase the usage of Cocoon across the usual boundaries. And those who had a look at Corona know that the code is of high quality in terms of comprehensibility, extensibility and modularity which is mostly due to his great development skills. Steven's contributions have been done in his free time so far which shows that Corona is a personal interest of him and I'm sure that when Corona takes off he will be around to improve and enhance it even further. Please cast your votes: here's my +1
Re: [vote] Luca Morandini as new Cocoon committer
+1 Ralph David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. Luca participates at the Cocoon dev and users mail lists since 2001, being more active again recently. http://cocoon.markmail.org/search/?q=morandini shows that there are many contributions to the lists and to code and docs. He also uses Cocoon as part of the Fins and Geoid projects. Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
Re: [vote] Andreas Hartmann as new Cocoon committer
+1 Ralph David Crossley wrote: I propose Andreas Hartmann as a new Cocoon committer and PMC member. Andreas already has commit access to Cocoon by virtue of being a committer at Apache Lenya. This will formalise his status at Cocoon and enable him to be a PMC member. Andreas has been participating at the Cocoon dev and users mail lists since late 2001. He has recently been participating in dev discussions and providing comments to issues and some patches. http://cocoon.markmail.org/search/?q=hartmann Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
Re: [vote] Thorsten Scherler as new Cocoon committer
+1 Ralph David Crossley wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. Thorsten already has commit access to Cocoon by virtue of being a committer at Apache Lenya and Apache Forrest. This will formalise his status at Cocoon and enable him to be a PMC member. Thorsten has been participating at the Cocoon dev and users mail lists since late 2002. He has recently been making some docs edits and participating in dev discussions and making suggestions for improvements and providing some patches. http://cocoon.markmail.org/search/?q=scherler Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04 So please cast your votes. -David
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
+1 Ralph Andrew Savory wrote: Hi, It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. Jasha has been active on the Cocoon mailing lists since the start of 2006 (http://cocoon.markmail.org/search/?q=Joachimsthal). He has contributed extensively on the user list and do the dev list. He has also done a talk on Cocoon at Apachecon EU and at the Cocoon GetTogether. During his work at Hippo he has become an expert on all things Cocoon! I believe he would make an excellent addition to the project. Please cast your votes. Here's mine: +1. Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: [Corona] PIpeline API
Carsten Ziegeler wrote: Now all these examples assume that the calling code knows the components. For my use case - and it's the same with the Cocoon sitemap - I've a description of a pipeline (think of the sitemap) which has just the name of the pipeline components to chain. A generic code instantiates these pipeline components - through a service registry - and does not know anything about these components apart from the fact that they are pipeline components. Can you show an example? Can they be declared as Spring beans and wired with the appropriate parameters, or at least beans that know how to dynamically obtain the correct information and then be referenced in the sitemap? Ralph
Re: [Corona] PIpeline API
Carsten Ziegeler wrote:
Ok, this all depends on what you consider configuration vs execution
information. If you look at the current Cocoon sitemap components
they've only a little configuration (everything that can be configured
in the components section of the sitemap). Most information is
passed in as execution information like the source to read from or any
additional paramter.
The component configuration can be easily done by a spring bean
configuration. The execution information is the interesting part as
this is different between each pipeline run.
You've seen the sitemaps and configuration we used. Often we would code
something like src=${request:bankid}/somedata.xml in the xconf (Spring
configuration). On every execution bankid would be dynamically resolved
so that every request could be on behalf of different banks. Of course,
the ability to do this is highly dependent on the components ability (or
the sitemap's) ability to perform variable resolution. We were often
force to do something like src=cocoon://${request:bankid}/somedata.xml
just to get around this.
Wouldn't liberal use of this concept solve the problem?
So, some pseudo code could look like this:
// read configuration of pipeline from somewhere
String type = // the component type
Map m = // the execution information
Transformer t = springContext.getBean(type);
t.setup(m);
Now, my configuration of the pipeline is actually stored in a JCR :)
but this is comparable with using the sitemap.xmap. Of course it
should contain a src information for the transformer to work.
Are you just getting the pipeline via WebDav? If so that isn't really
any different. If you are using the JCR API that could probably just be
abstracted into a JCR protocol handler.
Am I missing something?
Ralph
Re: Spring Configurator - filter/include strategy
Carsten Ziegeler wrote: Now I was very brief as I'm not 100% sure how the final solution in jetspeed looks like. Ok, our spring configurator includes all files located at a specific location and adds all bean definitions found there. The jetspeed guys enhanced the spring bean configuration format to have conditionals inside a bean xml definition, so something like (don't quote me on the syntax): j:if test=database.derby bean name=database ...the derby bean j:if j:else bean name=database ...the hsqldb bean /j:else Wow. It looks like Maven 1 jelly code. Next you will see for loops and ant tasks! I'm not crazy about XML as a programming language. The information needed to make decisions should be in the XML, not the logic. Ralph
Maven dependencies on itself.
Maybe this won't strike you as strange but it did me. I ran a mvn install on a project using 2.0.9. In the course of that maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-project-2.0.9 were downloaded, installed into the local repo and then used in the build. As you would expect this is due to the use of the various plugins used during the build. Knowing what I know about maven I understand why this us. But the question remains, doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven 2.0.9 jars?
Re: Maven dependencies on itself.
Rats. Please ignore. Wrong list. Ralph Goers wrote: Maybe this won't strike you as strange but it did me. I ran a mvn install on a project using 2.0.9. In the course of that maven-project-2.0, maven-project-2.0.6, maven-2.0.7, and maven-project-2.0.9 were downloaded, installed into the local repo and then used in the build. As you would expect this is due to the use of the various plugins used during the build. Knowing what I know about maven I understand why this us. But the question remains, doesn't this just seem wrong? Shouldn't maven 2.0.9 only use maven 2.0.9 jars?
Re: What is Corona?
Reinhard, I'm really looking forward to the documentation on this. To be honest, I am not sure I will ever be using Cocoon as a whole again but I can think of many cases where just using the pipeline would be valuable. I would suggest that if Corona is really as independent as it sounds then it should reside in its own subproject. This will keep dependencies from creeping back in and also make it clear that it is independent. Another thought is that if the Pipeline is completely abstracted then maybe it would be possible to build Cocoon on other kinds of pipelines. Ralph Reinhard Pötz wrote: Kamal Bhatt wrote: Grzegorz Kossakowski wrote: 5. Having a serious look into Corona. Forgive my ignorance, but I assume you are not risking blindness or are intending to drink lots of beer, so what is Corona? At Indoqa we have been working on a complete rewrite of Cocoon that we called Corona. The most basic module of Corona is the 'corona-pipeline' module. It is easily embeddable into any Java application because it comes with no dependency but the classes coming with the JRE. Here is an example for the pipeline API: Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator( PipelineTest.class.getResource(/test.xml))); pipeline.addComponent(new XSLTTransformer( PipelineTest.class.getResource(/test.xslt))); pipeline.addComponent(new XMLSerializer()); pipeline.execute(null, System.out); We also had the chance to tidy up a lot of things because the core of Cocoon isn't easily comprehensible after having been under development for about 7 years. On top of corona-pipeline we put the corona-sitemap module. It implements more or less the sitemap language that you know from Cocoon 2.x. Like Cocoon 2.2 the sitemap components are managed by Spring but the dependency on Spring should be easily replaceable because it is hidden behind an interface whose implementation class is really simple. The third layer of Corona is the 'corona-servlet' module. It provides a servlet that can be used together with the servlet-service framework. From my POV the most important features have been implemented by now. Some things have to be cleaned up and error reporting has to be improved but I'm optimistic that this will happen in the next few weeks. Additionally we will donate another module to Corona that provides a way to implement controller logic for RESTful web applications/services. Apparently the two missing things are documentation (I've already started with it) and an alpha-1 release. Of course the latter needs to be discussed by this community. For this purpose I will start a separate thread soon.
Re: svn commit: r666946 - in /cocoon/branches/BRANCH_2_1_X/tools/targets: compile-build.xml init-build.xml
Until we need to take advantage of some Java 1.5 feature ;-) [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=666946view=rev Log: With minimum Java raised to 1.4.2 it is no longer necessary to have JDK-specific source directories.
Re: Java 1.5 [was svn commit: r579132 - in /cocoon/trunk/core/cocoon-core/src/test/java/org/apache/cocoon/transfo rmation:I18NTransformerTestCase.java I18NTransformerTestCase.java.disabl
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now I'm certain we won't be supporting 1.4 until 2010. Ralph Goers wrote: Carsten Ziegeler said: Although I guess everyone understood what I meant above, just a clarification: of course I meant that it only makes sense to stick with 1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical mass. There is no doubt that currently there are many people using/develeoping 2.2 in general. We just switched our Cocoon deployment in production from IBM 1.4 to Sun 1.5 and got at least a 25% performance improvement. Java 1.6 is out. It seems nuts to me to continue to target 1.4 on an as yet unreleased new version of Cocoon. However, if you view this as a code change then the voting rules state that a single -1 vetoes the proposal, and we got that before. Unless the -1 is rescinded I fear we will be stuck at 1.4 until 2010. Ralph
Re: [proposal] Announcement mail for Cocoon 2.2.0 FINAL
I would suggest that the wording be changed slightly to remove the word FINAL. The title should be Apache Cocoon 2.2.0 Released. Released is correct because it is the verb in the sentence. The first sentence should also be The Apache Cocoon Community is proud to announce the release of Cocoon 2.2.0. Ralph James Cowie wrote: Hi people, just made some small little tweaks. enjoy the evening. J. On Mon, 2008-04-28 at 20:08 +0200, Reinhard Pötz wrote: Here is my proposal for the announcement mail. It's a copy of my last mail with the only difference that the version numbers got updated. I know it could be done better but I don't have enough time these days. Any feedback? ~~~ Apache Cocoon 2.2.0 FINAL Released Apache Cocoon 2.2.0 FINAL Release. The Apache Cocoon Community is proud to announce the final release Cocoon 2.2.0. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Apache Cocoon is now a Spring-Based framework (Version 2.2.X). Built around the concept of separating tasks into blocks. Cocoon implements this concept by implementing component pipelines, each component within the pipeline preforming a different operation. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. Cocoon 2.2 introduces blocks. A block is the unit of modularization in Cocoon (in comparison: Eclipse uses the term plugins, OSGi uses bundles). Everything that goes beyond what Cocoon provides in its core modules (Spring integration, sitemap and pipeline implementation) is provided as block (see below). Custom Cocoon applications are also developed as blocks. A block can provide the following features: Cocoon 2.2 introduces the idea of blocks. A block is the unit of modularization in cocoon, allowing the framework to be built upon. (in comparison: Eclipse uses the term plugins, OSGi uses bundles). Everything that goes beyond what Cocoon provides in its core modules (Spring integration, sitemap and pipeline implementation) is provided as block (see below). Custom Cocoon applications are also developed as blocks. A block can provide the following additional features: * general servlet services (any servlet can be managed by the Cocoon servlet-service framework), * special services that provide pipelines as services, * component services (Spring beans, Avalon services/components), * a container for classes and resources. A block is packaged as a Java archive (jar) following certain conventions concerning the directory structure. Find information about the new features at http://cocoon.apache.org/2.2/1420_1_1.html. To read more information about the new features within Cocoon 2.2.0 please go to: http://cocoon.apache.org/2.2/1420_1_1.html. Alternatively for more information about Apache Cocoon 2.2, please go to http://cocoon.apache.org or follow our getting started guide at http://cocoon.apache.org/2.2/1159_1_1.html. The release artifacts are available from the central Maven repository (http://repo1.maven.org/maven2/) or you can download them from the distribution area (http://cocoon.apache.org/1284_1_1.html). - o - Additionally we are pround to announce some additional releases: SUBPROJECTS --- * Cocoon Servlet-Service Framework 1.0.0 The Servlet Service Famework easy use of servlets as components which can communicate with other servlets. The current implementation is based on Spring 2.5. Dependencies: There are no dependencies on Cocoon core libraries at all. http://cocoon.apache.org/subprojects/servlet-service/1.0/ * Cocoon Configuration 1.0.2 The Cocoon Configuration subproject provides basic support for configuring web applications. Its current implementation, the Spring Configurator, is a useful component providing support in common configuration issues when using the Spring framework. Dependencies: There are no dependencies on Cocoon core libraries at all. http://cocoon.apache.org/subprojects/configuration/1.0/ Additional Cocoon 2.2.0 BLOCKS. -- * Cocoon Ajax 1.0.0 Partial page and form reloads http://cocoon.apache.org/2.2/blocks/ajax/1.0/ * Cocoon Apples 1.0.0 Pure Java implementations of controller logic. * Cocoon Auth 1.0.0 Authentication and authorization of pipelines and control-flow based Cocoon applications. http://cocoon.apache.org/2.2/blocks/auth/1.0/ * Cocoon Batik 1.0.0 Create Scalable Vector Graphics (SVG) using Cocoon pipelines.
Re: [vote] Release Cocoon 2.2-final
You going to the happiest place on earth? Isn't that Carsten's favorite place? Never having been (Disneyland is only 1 hr from here) I can't whether Orlando is much of a culture shock but I somehow doubt it. Try New York, San Francisco or Hollywood for that. Joerg Heinicke wrote: On 02.04.2008 11:36, Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. Find instructions about how you can test in a seperate mail. Report your findings to that thread and use this one for voting only. Thanks! +1 Unfortunately without testing. I planned to do it but haven't made it ... and in few hours I'm leaving for 1 week of American culture shock: Orlando, Florida :) Joerg
Re: Exploring Corona
Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Ralph Steven Dolg wrote: Carsten Ziegeler schrieb: Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? url.openConnection() actually returns a subclass of URLConnection depending on the protocol of the URL. So own protocol implementations can return own subclasses that implement this (and other methods) accordingly. And - at least theoretically - provide additional methods for handling specific stuff, e.g. expiration dates. Carsten
Re: JNet integration
Carsten Ziegeler wrote: Hmm, I don't think so. Imagine a pipeline java api just taking a uri for the sources used in the pipeline. That's simple and easy. Now, you can use the source resolver on top of that, resolve your sources and you get a uri from your source that you can put into the pipeline api. That's neither a mess nor does it require more java coding. That sounds good in theory, but the proof is in when you actually try to do it with caching enabled. As I said, I'm not really too interested in the non-caching use case as I view that as the minority use case. Furthermore, the non-caching use case can always be dealt with by using the caching use case and just turning off the cache. So you build this pipeline API that only uses java.net. Now you want to build pipelines that cache. Does the Source now have to show through the caching version of the pipeline API? If it does you will have a real mess as now users of pipelines have to determine whether they are caching or non-caching just to determine what methods they can use. Ralph
Re: Layered software designs
Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know.
Re: Layered software designs
Steven Dolg wrote: Ralph Goers schrieb: Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. Just curious - do you have doubts, that this is achievable specifically with Java, or generally with any language? Taking 5 or 6 concepts (interfaces?) and trying to tie them together can get quite messy in Java. C++ could use multiple inheritence. While that would work it also brings along all the problems all the problems multiple inheritence introduces. I'm sure there are other languages that might tie these concepts better, but off hand I can't think of one. I'm also sure there are some interesting ways to do this in Java. Whether they end up being complicated (either to maintain or use) remains to be seen. I'm all for letting whoever wants to move forward on this and see what they come up with. But I won't be willing to accept it until it supports caching. Ralph
Re: JNet integration
I had to create a class at work for handling some files. I started with an input stream. What I needed, though, required caching and being able to check whether the file was still valid. In this case I soon realized that I would have to reinvent the Excalibur Source interface since I had to cache the Validity (or something like it) along with the information about the file. In the end it made far more sense to just use the Source interface. I ended up extending the Excalibur Source implementations or creating my own though, as my Validity checking didn't match any of the existing implementations exactly. The point is, if you are planning on caching your files and checking whether they are valid or not just using java.net, etc. isn't going to be sufficient. Ralph Grzegorz Kossakowski wrote: Carsten Ziegeler pisze: I agree that our Environment abstraction was awkward - it introduced abstraction that never was a real abstraction and mostly duplicated existing, quite nice servlet API. At least now I fail to see coherent, nice to use standard Java API that Excalibur's Source and SourceFactory duplicates. As for now I can only see obstacles like: new URL(blabla/foo); will fail with java.net.MalformedURLException: no protocol: blabla/foo so one must use: new URL(baseURL, blabla/foo); Who will judge if given path is relative and requires baseURL instance? How one will get this baseURL instance? Guys, it's non-sense...
Re: JNet integration
I think you are out of your mind. (Not seriously). I have to tell you, Cocoon without caching pipelines would suck so bad with performance problems you would give it the boot in very short order. Even without Cocoon, as soon as you start doing anything serious caching will become necessary. I'll give you a trivial example. I wrote my own I18n implementation for use with JSF and used Excalibur Source to read an XML properties file containing the keys and values. The first implementation checked to see if the file was valid for every key that was read. This didn't perform well at all and I changed my Validity so that the file validity was only checked once per Request. This made it so the overhead of this utility was not noticeable. Now imagine that instead of just checking the validity I had been actually reading the file for every key! Ralph Reinhard Poetz wrote: Once again, my goal is that if you use e.g. Corona in its simplest form, I don't want to make everybody and his dog depend on JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL object is enough for simple use cases of a pipeline API. Yes, I understand that when it comes to caching pipelines, you need more, but not everybody needs caching pipelines. For that purpose there could be a CacheableFileGenerator, etc. If you are right and it is difficult or even impossible to remove the dependencies on source/sourceresolve/xmlutils/jnet, then be it. I withdraw my example Url(servlet:...) from above. When we can switch to sourceresolve 3.0, the dependency graph will get smaller anyway. The main benefit from using URLs (instead of the SourceResolver) comes from simple use cases, e.g. you need a pipeline in your Java application that reads in some XML file, performs some transformations and finally creates a PDF document. FWIW, using URLs should be all that you need.
Re: SourceResolver in SSF
I have no problem with merging the PMCs. I am not in favor of merging the source code. Carsten Ziegeler wrote: Grzegorz Kossakowski wrote: Ralph Goers pisze: I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Maybe it's better that Carsten explains what he meant. :) Yepp I meant we could pull out the code we use from Excalibur into our svn and therefore under our control *without* changing package names, artifact ids etc. We just establish them as *our* sub projects. So, there is no change from a user pov (I mean other users as cocoon), but we get full control over the code. Now we could have the same by just bringing all cocoon developers over to Excalibur. We could also merge the two projects? Carsten
Re: SourceResolver in SSF
As a user of sourceresolve independent of Cocoon I would be -1 on moving it into Cocoon. If it goes anywhere I'd prefer commons. Carsten Ziegeler wrote: Now, I think that this will be over time the best solution *if* we can keep the excalibur package names - but I think that should be possible. Let's face it, Excalibur is more or less a dead project. The stuff there is useful and used in some projects, but there is no community anymore to support stuff. We are the strongest users of some of the stuff there (sourceresolve, xml, store), so moving these things seems to be a good choice. The problematic part is the time frame. I would suggest to just copy the jnet classes to SSF to be able to release SSF in a short time frame. We can then sort out the details after Easter. WDYT? Carsten
Re: SourceResolver in SSF
I'm not sure what JNet actually is, but the part I was referring to was where Carsten was talking about Excalibur being dead and pulling out the few pieces we use. Grzegorz Kossakowski wrote: Ralph Goers pisze: As a user of sourceresolve independent of Cocoon I would be -1 on moving it into Cocoon. If it goes anywhere I'd prefer commons. Ralph, I'm not sure if you have followed the whole thread. We don't want to tie JNet code with Cocoon but only to establish a subproject of Cocoon and keep it still independent in terms of code dependencies. This way you will still be able to use it outside the Cocoon.
Re: Maintenance Release 2.1.12
+1 Carsten Ziegeler wrote: Hi, I had the thought of doing 2 or 3 maintenance releases of 2.1.x (if there are changes) per year. Following this spirit I would like to cut a 2.1.12 sometime during April. Carsten
Re: [2.2] Weird NPE when concurrency
Could you post the stack trace?
Thorsten Scherler wrote:
Hi all,
we have build a webapp based on cocoon 2.2. Everything is working fine
if a single person is using the app, but as soon as we have concurrent
user the code fails with NPE in different lines of the code.
My questions are:
Every pipeline is thread safe, right?
The mounts to the different servlet (blocks) is synchronized, right?
Is there a connection timeout for inner block communications?
The architecture is as follow:
main webapp - mounts dispatcher sitemap (from block)
Main match:
map:match pattern=**.html
map:generate src=lm://resolve.structurer.{1} type=jx
map:parameter name=lenient-xpath value=true/
map:parameter name=getRequest value={1}/
map:parameter name=contextPath
value={request:contextPath}/
map:parameter name=getRequestExtension value=html/
/map:generate
map:transform type=dispatcher
map:parameter name=cacheKey value={0}/
map:parameter name=validityFile
value=lm://resolve.structurer.{1}/
map:parameter name=request value={1}/
map:parameter name=type value=html/
map:parameter name=hooksTransformer
value=lm://hooks-to-html.xsl/
/map:transform
map:transform src=lm://namespace-stripped/
map:transform src=lm://strip-dispatcher-remains-html.xsl/
map:serialize type=xhtml/
/map:match
salu2
Re: Final 2.2 release?
Yes, I fixed 2108. If you are happy that the fix hasn't caused any other problems then I will close it. Grzegorz Kossakowski wrote: Carsten Ziegeler pisze: Hi, did you know that I bought one of those Grumpy shirts last time I visited WDW? So, I *have* to ask what the current plans for the long awaited final release of 2.2 is? Hi Carsten, I think that 2.2 is ready for a final release. JIRA does not report any outstanding serious issues apart from this one: https://issues.apache.org/jira/browse/COCOON-2108 which seems to be fixed by Ralph in r609282[1]. It would be good if Ralph who reopened that issue could confirm his fix and close it. Apart from JIRA issues there was one very serious problem: lack of any documentation on Servlet Service Framework. I was working on writing docs some time ago and I will continue to do so in upcomming days so you can expect something complete really soon. To sum up, it's certainly right time to start preparing the release. [1] http://svn.apache.org/viewvc?rev=609282view=rev
Re: svn commit: r611306 - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-additional-sample/pom.xml core/cocoon-core/pom.xml core/cocoon-webapp/pom.xml
Grzegorz Kossakowski wrote: In contrast to CTemplates or CForms, no developer is using XSP actively at the moment. How could you possibly know that?
Re: [ANN] Apache Cocoon 2.1.11 Released
Thanks Carsten. I don't get the last paragraph though. Why would we provide more information about 2.1.10 when the announcement is for 2.1.11? The changes.html link has almost nothing under 2.1.11 so I assume the reference to 2.1.10 is correct? Ralph Carsten Ziegeler wrote: Apache Cocoon 2.1.11 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. For more information about Apache Cocoon 2.1.10, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
Rats. Sorry. I was trying to squeeze that in when I had free time and I just get so used to skipping the tests since every time I've tried to run them my build has failed. I shouldn't have assumed they were still not working. To be honest when I was working on this I was just very frustrated at how much more complicated 2.2 is and was just looking for the simplest way to get VariableResolvers working everywhere like it does in 2.1. I spent hours over the weekend trying to get all this working. I should have raised some of these issues on the list before I checked it in: 1. Why on earth is VariableResolverFactory doing a lookup on StringTemplateParserVariableResolver.ROLE? Spring is supposed to free you to allow any implementation of an interface - or is StringTemplateParserVariableResolver the only acceptable implementation? (In which case, why is it even configurable via Spring?). It seems to me this should be replaced with VariableResolver.ROLE. 2. Does PreparedVariableResolver (the resolver in 2.1) still work? If it does I can have BridgeElementParser register it and then have SitemapElementParser replace the VariableResolver bean with StringTemplateParserVariableResolver. I'll give this a try and see what happens. Of course, it may have the same dependency problems. BTW - I couldn't find a reference to LegacyVariableResolver anywhere. Did you really mean LegacySitemapStringTemplateParser? Ralph Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282 URL: http://svn.apache.org/viewvc?rev=609282view=rev Log: Created XPathXMLFileModule to fix problems with XMLFileModule. Added getAttributeValue to JXPathHelper and changed all references to getAttribute to use it instead. Moved registration of VariableResolver to BridgeElementParser from SitemapElementParser to make it available to all Avalon components (i.e. input modules). Ralph, move of registration of VariableResolver broke[1] our testing environment because now LegacyVariableResolver is added to the environment for every test execution but its dependencies (referenced beans) are not. I'm not sure how to fix this at the moment but I will try to have a look in upcomming days. Anyway, I have a request to all committers: please test your changes before committing anything. It's just as simple as executing mvn clean install from root directory. [1] http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020projectId=51
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
Come to think of it, although it is a pretty lame excuse, the reason I ran with tests disabled is I just cut and pasted the command line from the README - I can never remember the format since -P allblocks isn't something you normally do with maven. Perhaps the README should be changed? It should only be for developers after all. Ralph Goers wrote: Rats. Sorry. I was trying to squeeze that in when I had free time and I just get so used to skipping the tests since every time I've tried to run them my build has failed. I shouldn't have assumed they were still not working. To be honest when I was working on this I was just very frustrated at how much more complicated 2.2 is and was just looking for the simplest way to get VariableResolvers working everywhere like it does in 2.1. I spent hours over the weekend trying to get all this working. I should have raised some of these issues on the list before I checked it in: 1. Why on earth is VariableResolverFactory doing a lookup on StringTemplateParserVariableResolver.ROLE? Spring is supposed to free you to allow any implementation of an interface - or is StringTemplateParserVariableResolver the only acceptable implementation? (In which case, why is it even configurable via Spring?). It seems to me this should be replaced with VariableResolver.ROLE. 2. Does PreparedVariableResolver (the resolver in 2.1) still work? If it does I can have BridgeElementParser register it and then have SitemapElementParser replace the VariableResolver bean with StringTemplateParserVariableResolver. I'll give this a try and see what happens. Of course, it may have the same dependency problems. BTW - I couldn't find a reference to LegacyVariableResolver anywhere. Did you really mean LegacySitemapStringTemplateParser? Ralph Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282 URL: http://svn.apache.org/viewvc?rev=609282view=rev Log: Created XPathXMLFileModule to fix problems with XMLFileModule. Added getAttributeValue to JXPathHelper and changed all references to getAttribute to use it instead. Moved registration of VariableResolver to BridgeElementParser from SitemapElementParser to make it available to all Avalon components (i.e. input modules). Ralph, move of registration of VariableResolver broke[1] our testing environment because now LegacyVariableResolver is added to the environment for every test execution but its dependencies (referenced beans) are not. I'm not sure how to fix this at the moment but I will try to have a look in upcomming days. Anyway, I have a request to all committers: please test your changes before committing anything. It's just as simple as executing mvn clean install from root directory. [1] http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020projectId=51
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
OK. So using PreparedVariableResolver fixes the problems with the dependencies. I've committed the change. But I am still getting 1 unit test failure in cocoon core - CachingSourceTestCase is failing on line 88. How could this possibly have anything to do with what I changed? Ralph Goers wrote: Rats. Sorry. I was trying to squeeze that in when I had free time and I just get so used to skipping the tests since every time I've tried to run them my build has failed. I shouldn't have assumed they were still not working. To be honest when I was working on this I was just very frustrated at how much more complicated 2.2 is and was just looking for the simplest way to get VariableResolvers working everywhere like it does in 2.1. I spent hours over the weekend trying to get all this working. I should have raised some of these issues on the list before I checked it in: 1. Why on earth is VariableResolverFactory doing a lookup on StringTemplateParserVariableResolver.ROLE? Spring is supposed to free you to allow any implementation of an interface - or is StringTemplateParserVariableResolver the only acceptable implementation? (In which case, why is it even configurable via Spring?). It seems to me this should be replaced with VariableResolver.ROLE. 2. Does PreparedVariableResolver (the resolver in 2.1) still work? If it does I can have BridgeElementParser register it and then have SitemapElementParser replace the VariableResolver bean with StringTemplateParserVariableResolver. I'll give this a try and see what happens. Of course, it may have the same dependency problems. BTW - I couldn't find a reference to LegacyVariableResolver anywhere. Did you really mean LegacySitemapStringTemplateParser? Ralph Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282 URL: http://svn.apache.org/viewvc?rev=609282view=rev Log: Created XPathXMLFileModule to fix problems with XMLFileModule. Added getAttributeValue to JXPathHelper and changed all references to getAttribute to use it instead. Moved registration of VariableResolver to BridgeElementParser from SitemapElementParser to make it available to all Avalon components (i.e. input modules). Ralph, move of registration of VariableResolver broke[1] our testing environment because now LegacyVariableResolver is added to the environment for every test execution but its dependencies (referenced beans) are not. I'm not sure how to fix this at the moment but I will try to have a look in upcomming days. Anyway, I have a request to all committers: please test your changes before committing anything. It's just as simple as executing mvn clean install from root directory. [1] http://vmbuild.apache.org/continuum/buildResult.action?buildId=35020projectId=51
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
Well, that just means I'm going to be up a while trying to figure out why. But thanks. It's good to know that it is working again. I also verified that the XPathXMLFileModule sample still works, so that is good. Then I just need to write some unit tests for it. I modified my own copy of SitemapComponentTestCase years ago to provide support for unit testing input modules. I'll have to dig that back up I guess. Joerg Heinicke wrote: On 08.01.2008 22:59, Ralph Goers wrote: But I am still getting 1 unit test failure in cocoon core - CachingSourceTestCase is failing on line 88. How could this possibly have anything to do with what I changed? Since our Continuum build now runs successful it seems to be an issue with your environment. Joerg
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
I put slashdot.org in my browser on that machine and it took quite a
while to display but it did. I notice that the unit tests pause for
quite a while on that test. I'm not sure why.
Anyway, I changed the 5 to 30 and it still fails. Should unit tests
really be going to external resources?
Ralph
Joerg Heinicke wrote:
On 08.01.2008 23:23, Joerg Heinicke wrote:
But I am still getting 1 unit test failure in cocoon core -
CachingSourceTestCase is failing on line 88. How could this possibly
have anything to do with what I changed?
Since our Continuum build now runs successful it seems to be an issue
with your environment.
Or - since it goes to a remote source - 5 s is just too short;
public void testCachingURI() throws Exception {
String uri = cached:http://slashdot.org/?cocoon:cache-expires=5;;
CachingSource source;
source = (CachingSource) resolver.resolveURI(uri);
CachingSource.SourceMeta meta1 = source.getResponseMeta();
resolver.release(source);
source = (CachingSource) resolver.resolveURI(uri);
CachingSource.SourceMeta meta2 = source.getResponseMeta();
resolver.release(source);
// Source is cached -- same meta data
assertSame(meta1, meta2);
If this test fails reliably for you can you please try to increase the
cache-expires parameter on the uri?
Joerg
Re: Question about sample site in trunk
Maybe we are on the same page, but I'm unclear what you mean by include. A cocoon release should consist of nothing more than deploying artifacts to the maven repository. End users should be getting the release by specifying the version number of the release in the archetypeVersion. To create the sample site they should do: mvn archetype:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-archetype-samples -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=samples mvn install mvn jetty:run IIRC the source can also be placed in the maven repository, so if they want to see what the source for samples look like we should be able to provide something that will retrieve them. Even if we can't do this, there are 2 things I do not want to see. 1) End users have to download all the source for Cocoon or 2) End users have to individually download a bunch of zips to get the source for all the various sample blocks. Ralph Joerg Heinicke wrote: On 08.01.2008 14:45, Grzegorz Kossakowski wrote: We were not shipping samples because samples should depend on released artifacts, only. Anyway, I agree that we need to find a way for distribution of our samples. However, I wonder how we will treat them? As official released packages with version number schemes, etc.? I would like to go with just creating zip archives containing source code of all our samples that depend on released artifacts. We would update such archive from time to time, as need occurs. I don't think we need any more formalization. WDYT? I don't know if it is put in question but IMO we still need an actual Cocoon 2.2 release which is more than core but also includes as many blocks as possible (the ones converted and working). Where is the problem to include all these blocks with their samples? Joerg
Re: Question about sample site in trunk
No. We could take advantage of http://maven.apache.org/ant-tasks.html to create various ant scripts to do that. However, since I'm still not sure what this supposed support for non-maven builds really looks like it is hard to have a good answer to the question. Ralph Joerg Heinicke wrote: On 09.01.2008 00:11, Ralph Goers wrote: Maybe we are on the same page, but I'm unclear what you mean by include. A cocoon release should consist of nothing more than deploying artifacts to the maven repository. End users should be getting the release by specifying the version number of the release in the archetypeVersion. That's exactly what I don't want to have as ONLY option. IMO we must provide the classic kind of a release. Otherwise a comment like we are going to put into the FAQ (You really don't need Maven!) is also just a joke. Should one grab each jar from the Maven repository by hand? Joerg
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
I changed the expire time from 5 to 10 and then changed the sleep time
to 11000. That got the unit test to pass.
I'm not sure what to do about this. Having a unit test rely on an
external resource is very bad practice just for this reason. Worse, if I
didn't have an active internet connection at all I couldn't run the unit
tests at all, even if I did mvn -o.
This test case does have an interesting history. Up until Aug 23, 2006
it was using a local file. On that date is was modified to point at
google. On March 7, 2007 it was modified to point to slashdot with the
comment that google's content type is inconsistent. At that time the
expire time was set to 1. It was changed to 2 on May 1, 2007 and then to
5 on Nov 13, 2007. Apparently it still doesn't work everywhere. So the
question is, why was it changed from using a local file in the first place?
I'm really hesitant to just up it to 10.
Ralph
Ralph Goers wrote:
I put slashdot.org in my browser on that machine and it took quite a
while to display but it did. I notice that the unit tests pause for
quite a while on that test. I'm not sure why.
Anyway, I changed the 5 to 30 and it still fails. Should unit tests
really be going to external resources?
Ralph
Joerg Heinicke wrote:
On 08.01.2008 23:23, Joerg Heinicke wrote:
But I am still getting 1 unit test failure in cocoon core -
CachingSourceTestCase is failing on line 88. How could this
possibly have anything to do with what I changed?
Since our Continuum build now runs successful it seems to be an
issue with your environment.
Or - since it goes to a remote source - 5 s is just too short;
public void testCachingURI() throws Exception {
String uri = cached:http://slashdot.org/?cocoon:cache-expires=5;;
CachingSource source;
source = (CachingSource) resolver.resolveURI(uri);
CachingSource.SourceMeta meta1 = source.getResponseMeta();
resolver.release(source);
source = (CachingSource) resolver.resolveURI(uri);
CachingSource.SourceMeta meta2 = source.getResponseMeta();
resolver.release(source);
// Source is cached -- same meta data
assertSame(meta1, meta2);
If this test fails reliably for you can you please try to increase
the cache-expires parameter on the uri?
Joerg
Re: Question about sample site in trunk
How hard would it be to create an archetype to create the pom automatically? Users would then either just build and run it or edit it first to remove stuff they don't care about. Telling them to create pom.xml inheriting from core-cocoon-webapp still requires that they a) know how to do that and b) know what samples exist that they can add. Ralph Vadim Gritsenko wrote: On Jan 7, 2008, at 2:32 AM, Ralph Goers wrote: But if they want to build the sample site and run it what would they do? Create pom.xml inheriting from core/cocoon-webapp and add dependencies to all of the *-sample blocks you want, followed by mvn install jetty:run should do it. Vadim
[jira] Closed: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed COCOON-1574. --- Resolution: Fixed Fix Version/s: 2.1.11 Affects version (Component): Parent values: Components: Sitemap(10152). Fix version (Component): Parent values: Components: Sitemap(10229). XPathXMLFileModule is now also available in trunk. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers Fix For: 2.1.11 I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2064) PropertySettings does not support run-mode (but documents that it does)
[ https://issues.apache.org/jira/browse/COCOON-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed COCOON-2064. --- Resolution: Fixed The javadoc has been updated. PropertySettings does not support run-mode (but documents that it does) --- Key: COCOON-2064 URL: https://issues.apache.org/jira/browse/COCOON-2064 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.10, 2.1.11 Reporter: Ellis Pritchard Assignee: Ralph Goers org.apache.cocoon.util.PropertySettings documents the following: * 2) context://WEB-INF/properties/[RUNNING_MODE]/*.properties *Default values for the running mode - the order in which the files are read is not guaranteed. The running mode support doesn't seem to actually be implemented. In addition, the properties facilities of Cocoon 2.1.10+ are not documented anywhere outside of the source, so many users may be unaware of this facility (I was). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r609282 [1/2] - in /cocoon/trunk: blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/modules/ blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resou
I didn't know about the plugin, but yes I knew I should have put the issue number in the commit. I just forgot to do it. Joerg Heinicke wrote: On 06.01.2008 04:35, [EMAIL PROTECTED] wrote: Author: rgoers Date: Sun Jan 6 01:35:48 2008 New Revision: 609282 URL: http://svn.apache.org/viewvc?rev=609282view=rev Log: Created XPathXMLFileModule to fix problems with XMLFileModule. Added getAttributeValue to JXPathHelper and changed all references to getAttribute to use it instead. Moved registration of VariableResolver to BridgeElementParser from SitemapElementParser to make it available to all Avalon components (i.e. input modules). Hi Ralph, I don't know if it just slipped through in this commit: If you add the issue number to the commit message, the SVN plugin for Jira can link the revision to the issue and adds nice links as it happened for your commit to 2.1 branch: https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel Joerg
Question about sample site in trunk
I know how to build the sample site in trunk from the source. However, this isn't the way a typical end user would like to do it. The online doc says to do mvn archetype:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0-RC2 -DgroupId=com.mycompany -DartifactId=myBlock1 to build your own block. But if they want to build the sample site and run it what would they do? I would think it would be rather simple (at least I hope so). This should be documented on the getting started page as I'm sure someone just getting started with 2.2 would want to do this. Ralph
Re: context protocol in trunk
So the context protocol is pretty much useless in trunk. I replaced it with blockcontext:/cocoon-core-main-sample/ and it works fine. It would be a lot nicer to do blockcontext:// and get the current block context but I'm not seeing anything keeping track of that. Ralph Ralph Goers wrote: It is specified as context://samples/modules/forrestconf.xml. Cocoon is looking for it in /projects/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/samples/modules/forrestconf.xml (very similar to where 2.1 would have looked for it). The file is actually located at /projects/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-core-main-sample/modules/forrestconf.xml. Grzegorz Kossakowski wrote: Ralph Goers pisze: Does the context protocol work in trunk? In the XMLFileModule sample it is resolving to the wrong location. To what location does it resolve?
RequestModule
I'm trying to test the change to JXPathHelper and have run into problems on the RequestModule sample. It fails in JXPath trying to process the attributeNames. The problem occurs because the attributeNames member of ReqeustWrapper is represented by an IndexedPropertyDescriptor instead of a PropertyDescriptor. When JXPath calls ValueUtils.getValue() it fails because the getReadMethod call returns null. This is because it is returned in getIndexedReadMethod instead. This does not happen in BRANCH_2_1_X where attributeNames is represented by a PropertyDescriptor. I believe this is happening because in trunk getAttributeNames is now overloaded where it wasn't in 2.1.x. The only way I can think of to fix this is to leave getAttributeNames() as is (returning the attribute names that are of global scope) and replace getAttributeNames(int scope) with getLocalAttributeNames() and have it only return the local attribute names. Any other ideas? Ralph
context protocol in trunk
Does the context protocol work in trunk? In the XMLFileModule sample it is resolving to the wrong location. Ralph Goers wrote: I'm trying to get XPathXMLFileModule working in trunk. However, before I can even get that far it doesn't look like XMLFileModule works. It fails saying it can't find forrestconf.xml. The full path is listed in the exception and indeed the file does not exist there. Instead, it is in a work directory. Any ideas on how to get these to work? Ralph
Re: RequestModule
I have fixed this and will be checking it in along with my other JXPathHelper and XPathXMLFileModule changes. The real problem here is that the Introspector uses an IndexedPropertyDescriptor whenever a getter exists with an int parameter. It thinks the int is an index into an array. So the scope on getAttributeNames was confusing the heck out of it. Ralph Ralph Goers wrote: I'm trying to test the change to JXPathHelper and have run into problems on the RequestModule sample. It fails in JXPath trying to process the attributeNames. The problem occurs because the attributeNames member of ReqeustWrapper is represented by an IndexedPropertyDescriptor instead of a PropertyDescriptor. When JXPath calls ValueUtils.getValue() it fails because the getReadMethod call returns null. This is because it is returned in getIndexedReadMethod instead. This does not happen in BRANCH_2_1_X where attributeNames is represented by a PropertyDescriptor. I believe this is happening because in trunk getAttributeNames is now overloaded where it wasn't in 2.1.x. The only way I can think of to fix this is to leave getAttributeNames() as is (returning the attribute names that are of global scope) and replace getAttributeNames(int scope) with getLocalAttributeNames() and have it only return the local attribute names. Any other ideas? Ralph
Re: context protocol in trunk
It is specified as context://samples/modules/forrestconf.xml. Cocoon is looking for it in /projects/cocoon/trunk/core/cocoon-webapp/target/cocoon-webapp/samples/modules/forrestconf.xml (very similar to where 2.1 would have looked for it). The file is actually located at /projects/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-core-main-sample/modules/forrestconf.xml. Grzegorz Kossakowski wrote: Ralph Goers pisze: Does the context protocol work in trunk? In the XMLFileModule sample it is resolving to the wrong location. To what location does it resolve?
trunk
I'm trying to get XPathXMLFileModule working in trunk. However, before I can even get that far it doesn't look like XMLFileModule works. It fails saying it can't find forrestconf.xml. The full path is listed in the exception and indeed the file does not exist there. Instead, it is in a work directory. Any ideas on how to get these to work? Ralph
Re: [PROPOSAL] Micro-Cocoon
Use the whiteboard. The only areas of concern I have is with regard to sub-sitemaps and resources. But I reserve judgment on that until I see what you come up with. Ralph Reinhard Poetz wrote: We at Indoqa have started to think about working on a slimmed down version of Cocoon 2.2 (Micro-Cocoon). By doing this we pursue a couple of goals: o increase the maintainability of Cocoon (Cocoon 2.2 is already a big improvement but still too complicated in some areas) o optimize Cocoon for the development of RESTful services o enable the usage of pipelines via a Java API o make Cocoon pipelines/sitemaps ready for the usage in OSGi environments o aspect-oriented profiling of pipelines o build upon the servlet-service-framework so that this reduced version can be run in parallel with a 2.2 application (in order to save already made investments) o reduce the dependencies to external libraries to a minimum o sitemaps as Spring bean definitions (mid-term goal) o pull pipelines (long-term goal) In order to reach these goals we want to start off with existing code, but then continue with removing o all dependencies on Avalon/Excalibur o the support for sub-sitemaps (no map:mount) o the support for sitemap-level components (no map:components) o the support for the cocoon-protocol o map:resource o map:view Having said this, I want to mention that, for us, the Micro-Cocoon effort is a feasability study, that we will conduct over the next 8 weeks. However, in order to make it not only based on theoretical assumptions, we also want to touch code. Since we think that this might be of interest for others too, we would like to work into a public repository, preferably the Cocoon whiteboard. We have also invited Grek who will come to Vienna for a couple of days and will support us with his expertise. Based on the result of the study, we will decide if/how we will continue. I know, that as I'm a Cocoon committer, I'm free to add anything which is somehow related to Cocoon to the whiteboard without asking before, but in this case I'm not sure about the impact on our community if we start off another effort on improving Cocoon (2.2 still hasn't reached a final release yet). Is it a good idea to use the Cocoon whiteboard? Or shall we go to Sourceforge, Apache Labs, or even do it only internally? etc. I highly appreciate your comments on the proposal itself as well as on the setting. Thanks.
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
[EMAIL PROTECTED] wrote: Creating the jira posted to the Cocoon Dev ML in June. Nobody commented. Should we consider that as no interest or no objections? I did not receive notification that nobody looked at the jira. What is the proper channel for more review? This list. If you want to advocate for something you can't just sit back and wait. This is true of any open source project. Carsten has reverted the commit and objects to improving creation of applications because some method exists that is better than the obvious one (that this commit tried to improve). The Cocoon-2.1 documentation has a hole where the application creation instructions belong. Should this discussion continue? Yes, unless you feel it isn't worth pursuing. No one is saying they don't agree with your objective. They just don't agree with the particular implementation. Ralph
Re: 2.1.11 release
I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08 Ralph Goers wrote: If I can't get it done in the next 24 hrs go ahead and do that. However, I'd really like my changes in 2.1.11 also. It has been an outstanding defect for several years. Grzegorz Kossakowski wrote: Ralph Goers pisze: I'm currently trying to get the XPathXMLFileModule into trunk. I was holding off committing until I had that working. However, I will be heading off to Seattle very early tomorrow until New Year's Eve so if I don't get it committed today it won't be included in your build - which is a very bad thing since several JXPath based input modules don't work right now (i.e - I'd have to vote -1 on the release until I get this fixed). I may just commit what I have for 2.1 and get trunk done when I get back. Unfortunately, I am very busy getting things ready for my grandkids birthday party so I have no idea if I'll get this completed today. What about reverting my change in 2.1.x branch that broke JXPath-based modules and introducing a new method in JXPathHelper just to make xmodule:flow-attr working properly? It's really not my favorite choice but it was me who broke XMLModule and I don't want to block a release. In trunk I opt for cleaner API at price of breaking back-compatibility. WDYT?
[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
[ https://issues.apache.org/jira/browse/COCOON-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554656 ] Ralph Goers commented on COCOON-1574: - I have checked in XPathXMLFileModule which can be used as a replacement for XMLFileModule. It differs from XMLFileModule by 1. It caches a DocumentInfo instead of a DocumentHelper. DocumentInfo contains the Document, its Validity, the url, the resolver and the expression cache. The expression cache is a ReferenceMap containing soft references. 2. DocumentInfo objects are cached in an externally configurable cache. The default implementation uses ehcache. 3. The soruce url can contain variables which will be resolved each time the input module is used. The cache key used is the url after resolving variables. 4. Both the cacheable and reloadable parameters can be specified as variables which will be resolved each time the module is called. 5. The amount of code run in a synchronized block is much smaller. XPathXMLFileModule performs about the same as XMLFileModule under light load. Under heavy load it experiences much more consistent behavior than XMLFileModule. In testing XMLFileModule showed a very large standard deviation in response time with a very large maximum response compared to the minimum. XPathXMLFileModule has a much smaller standard deviation and a smaller maximum response time. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: https://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Thanks for the explanation, except I'm still not clear what a connection name is. See below for my 2 cents. Grzegorz Kossakowski wrote: The only problem is that we have no way to check if given URI contains connection name or servlet ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current proposal are: a) add a plus sign after servlet ID (by Reinhard) b) add a exclamation mark at the very beginning of the path (by Vadim) My personal preference is a plus sign but as Reinhard already pointed out it does not matter that much because we usually won't be using absolute URIs directly. Yuck, yuck, yuck. (If you get the impression I don't like a or b you are on track). c) Use a different scheme to identify one vs the other. d) Use a different pattern. i.e conventional urls look like http://authority/path where authority can be a variety of things such as server[:port], [EMAIL PROTECTED]:port] and server can be a domain name or an ip address. In this case, you could do something like servlet://[EMAIL PROTECTED]/path which, if I understood you correctly. could be abbreviated to servlet://connection/path. For servlet id you could use the same syntax with servlet://[EMAIL PROTECTED]/path. Of course, since I don't really know what a connection is I have no idea if this makes sense, but it could certainly be abbreviated to servlet://@servlet_id/path. Or use servlet://[connection][:id]/path, although servlet://:Servlet_C/path still looks a little odd. + and : characters in uri's just plain look strange, even if they are allowed, unless they are used in a similar fashion to existing schemes. Also, not having the // in the uri makes one wonder just what the token before the first slash is. Everybody knows that whatever follows the double slashes is not part of the path so it is less confusing. -- o0o -- Now it's the time to give some description of static connection list problem. Currently one can define list of connection of a given servlet statically in XML config. If you compile a block there is no chance to add new connections to other servlets. Now, imagine situation that you have some application making charts and you create separate block (and servlet) for each datasource provider. For example, you create block that extracts some data from database and second one that extracts some data from mailbox. If you want to pull this data, you need to connect to these two blocks of course so you add them to your local connection list. Now you can compile your application and everything will be working fine. But what if you want to define another datasource for your charts, for example data from some web service? Of course you develop a new block that downloads and transforms interesting data but you need a way to inform your appliction that there is a third block. The most obvious way is to add connection to the third block but this involves recompilation of your application! The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute URIs so you don't need to define connections statically to other block. There would be also some discovery mechanism of available blocks, probably a generator, that would return you a list of blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you could reference them later on. I hope this helps you a little bit. I still don't quite get this connection thing. What I don't get is why this can't just be servlet://[EMAIL PROTECTED]/path? Or better yet, why shouldn't my application just reference a bean id and wire it to the block service in its Spring configuration (think Spring remoting)? Please reply, even though I'll be on a plane in a few hours. I'm sure I'll find time to look at email while I'm out of town. Ralph
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
[EMAIL PROTECTED] wrote: I committed/closed my Cocoon jiras as soon as I learned a Cocoon release was planned. This may be the final release of Cocoon-2.1 so every change must be committed or discarded. I wouldn't get your hopes up on this one. 2.2 is sufficiently different enough that I would not be surprised to see a 2.1.12 release even after 2.2.0. Ralph
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
In case you didn't know, people.apache.org/~jim lists solprovider as Paul Ercolino, a committer from Lenya. He opened Cocoon-2074 in June and listed the change then. No one ever commented on it. I'm not clear on what you are saying. Does your question I am wondering if a simple filtering=on statement can replace the previous code. mean you are wondering if he has really verified that his change works in all cases? Perhaps you could identify some of the things you think will cause problems if it is left this way? Ralph Antonio Gallardo wrote: Hi solprovider, I am wondering if a simple filtering=on statement can replace the previous code. I recall issues with files that become broken on the resources if we use filtering. And also some files we don't want on the final webapp. Best Regards, Antonio Gallardo.
JXPathHelper
I am going to have to revert the change below to JXPathHelper as it has
broken XMLFileModule. The sample site no longer works correctly.
Subject: svn commit: r575808 -
/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
Date: Fri, 14 Sep 2007 22:40:49 -
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
X-Mailer: svnmailer-1.0.8
Message-Id: [EMAIL PROTECTED]
X-Virus-Checked: Checked by ClamAV on apache.org
Author: gkossakowski
Date: Fri Sep 14 15:40:40 2007
New Revision: 575808
URL: http://svn.apache.org/viewvc?rev=575808view=rev
Log:
COCOON-2108: Construct xmodule:flow-attr does not accept document
object. Thanks to Hugh Sparks for contributing the patch and Kazo Csaba
for reporting the issue on mailing list.
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
URL:
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java?rev=575808r1=575807r2=575808view=diff
==
---
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
(original)
+++
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/modules/input/JXPathHelper.java
Fri Sep 14 15:40:40 2007
@@ -95,8 +95,7 @@
JXPathContext jxContext = JXPathContext.newContext(contextObj);
setup(setup, jxContext, modeConf);
-Object obj = jxContext.getValue(name);
-return obj;
+return jxContext.selectSingleNode(name);
} catch (Exception e) {
throw new ConfigurationException(Module does not support
+ name + + attribute., e);
}
[jira] Reopened: (COCOON-2108) xmodule:flow-attr Does not accept document objects
[ https://issues.apache.org/jira/browse/COCOON-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reopened COCOON-2108: - This patch causes XMLFileModule and anything based on AbstractJXPathModule or JXPathMetaModule to fail as they no longer receive the value of the element. xmodule:flow-attr Does not accept document objects -- Key: COCOON-2108 URL: https://issues.apache.org/jira/browse/COCOON-2108 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Reporter: Hugh Sparks Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN) Attachments: Cocoon-2.2-truck-JXPathHelper.java.patch, Cocoon-BRANCH-2.1.X-JXPathHelper.java.patch, xmodulePuzzle.txt Sending document objects from flowscript back to the pipeline using xmodule:flow-attr produces unexpected results. Also, the examples from the documentation do not work as described: http://cocoon.apache.org/2.1/861.daisy.html The most common error reported is: 'The object type: class java.lang.String could not be serialized to XML This issue was discussed recently on the cocoon-users mailing list. The thread was introduced by Kazo Csaba with the subject Sending DOM from flowscript to pipeline. (July 17, 2007) He has attempted to trace this behavior in the source code and believes that a possibly-inappropriate conversion to string occurs in some cases. Jason Johnston suggested moving the issue to JIRA. I've created a demonstration of this apparent bug and some related problems in this very brief example: http://www.csparks.com/xmodulePuzzle.txt I hope someone can fix or explain the correct usage of xmodule:flow-attr. Thanks to all, -Hugh Sparks, [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JXPathHelper
As far as I know the old implement wasn't buggy,it just always returned
text. It looks like it could have returned null and the code might not
handle that properly, but that isn't a problem in JXPathHelper. The
proper way to have done this would have been to either have created a
new method - since the return type was really always a String, although
it is specified as object, or to have gone and fixed everything that
that used getAttribute to work correctly. It looks like adding
if (result != null result instanceof Element) {
result = ((Element)result).getTextContent();
}
might fix this, but I'll have to add it to everything that uses
JXPathHelper.getAttribute, which doesn't seem quite right either. But
I'm testing this right now to see if it fixes this.
Ralph
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I am going to have to revert the change below to JXPathHelper as it has
broken XMLFileModule. The sample site no longer works correctly.
Hi Ralph.
Are you sure that simple revert is a solution? AFAIR previous behavior of
JXPathHelper.getAttribute() method was buggy too.
Re: JXPathHelper
I have verified that the code below gets my new XPathXMLFileModule
working again. However, I'm still not sure that is the correct thing to
do as the change essentially broke the contract. So although I could
make the same change in all the affected Cocoon classes any customer who
happened to use JXPathHelper for their own purposes would also have
problems.
Ralph
Ralph Goers wrote:
As far as I know the old implement wasn't buggy,it just always
returned text. It looks like it could have returned null and the code
might not handle that properly, but that isn't a problem in
JXPathHelper. The proper way to have done this would have been to
either have created a new method - since the return type was really
always a String, although it is specified as object, or to have gone
and fixed everything that that used getAttribute to work correctly. It
looks like adding
if (result != null result instanceof Element) {
result = ((Element)result).getTextContent();
}
might fix this, but I'll have to add it to everything that uses
JXPathHelper.getAttribute, which doesn't seem quite right either. But
I'm testing this right now to see if it fixes this.
Ralph
Grzegorz Kossakowski wrote:
Ralph Goers pisze:
I am going to have to revert the change below to JXPathHelper as it has
broken XMLFileModule. The sample site no longer works correctly.
Hi Ralph.
Are you sure that simple revert is a solution? AFAIR previous
behavior of
JXPathHelper.getAttribute() method was buggy too.
Re: JXPathHelper
So you have no problem breaking API contracts with end users on minor point releases? Grzegorz Kossakowski wrote: Ralph Goers pisze: I have verified that the code below gets my new XPathXMLFileModule working again. However, I'm still not sure that is the correct thing to do as the change essentially broke the contract. So although I could make the same change in all the affected Cocoon classes any customer who happened to use JXPathHelper for their own purposes would also have problems. I agree that fix for COCOON-2108 changed the contract but I don't agree it broke as I think it's been broken earlier. Issue COCOON-2108 was caused by the fact that getAttribute was doing something completely unexpected. Instead of returning an Object it returns String representation of Object. That's bad situation and if someone relies on bad API it's also his business to fix his code. I think the best is to introduce new method like getAttributeAsString and switch to it everywhere it's needed.
Re: JXPathHelper
http://marc.info/?l=xml-cocoon-devm=108266407019215w=2 Ralph Goers wrote: So you have no problem breaking API contracts with end users on minor point releases? Grzegorz Kossakowski wrote: Ralph Goers pisze: I have verified that the code below gets my new XPathXMLFileModule working again. However, I'm still not sure that is the correct thing to do as the change essentially broke the contract. So although I could make the same change in all the affected Cocoon classes any customer who happened to use JXPathHelper for their own purposes would also have problems. I agree that fix for COCOON-2108 changed the contract but I don't agree it broke as I think it's been broken earlier. Issue COCOON-2108 was caused by the fact that getAttribute was doing something completely unexpected. Instead of returning an Object it returns String representation of Object. That's bad situation and if someone relies on bad API it's also his business to fix his code. I think the best is to introduce new method like getAttributeAsString and switch to it everywhere it's needed.
Re: JXPathHelper
My numbering has nothing to do with yours... 1. The versioning manifest described in [1] used to be at http://cocoon.apache.org/versioning.html. Somewhere along the line that page was apparently removed. Probably because it wasn't being followed. There was a followup thread a while later where many committers didn't even remember we had passed this. 2. Personally I think 2.2 should be 3.0, but that is just me. Because of that I have no real problem breaking binary compatibility with it and so I definitely don't have a problem with what you are proposing there. 3. Welcome to the club. We've all been depressed at one time or another over how infrequently we do releases. But the list of issues shouldn't end there. For one, your original fix shouldn't have been able to go in without causing the build to test. The number of unit tests we have is abysmal. We can drastically improve this in 2.2 since maven makes it so easy to build and run them, but I don't think it is that hard in 2.1 either. I kind of find it amusing that you checked in this change 3 months ago and no one has noticed until now that the JXPath modules are all broken - at least on getting the values of elements anyway. Attributes still work. In the end I'm probably just going to let this slide unless someone else responds and says it will be a problem for them, partly for the reasons you cite with regards to JXPathHelper, partly because the existing method is a bit odd and partly for other reasons. I'll add the new method and fix the other classes as part of checking in XPathXMLFileModule (ironically, I made a new class because this version is not quite compatible with XMLFileModule). Ralph Grzegorz Kossakowski wrote: Ralph Goers pisze: So you have no problem breaking API contracts with end users on minor point releases? To be honest I was thinking about 2.2 mainly. Anyway, I agree with everything that has been said in the thread[1] mentioned by you but at the same time I see some subtle details: 1. JXPathHelper, even if not marked explicitly, should be considered as rather internal class. It has absolutely no Javadocs and does not look as a standard API. 2. Current behavior of getAttribute() method does not fulfill any API's needs as there are no documentation on how it is supposed to work. What's more current behavior is completely different from what one could expect taking javax.servlet.http.HttpServletRequest.getAttribute() as an example of similar functionality. 3. We are really bad on releasing and desperately bad on making minor releases. It was clearly shown by Antonio: http://article.gmane.org/gmane.text.xml.cocoon.devel/76241 I'm not sure if it's just me not being in good condition overall but when I read this list compiled by Antonio and realize how long it takes to make a patch release I become really depressed. Don't you think that waiting about three to four years to remove (first deprecate) some old code is too long? [1] http://marc.info/?l=xml-cocoon-devm=108266407019215w=2
Re: Preparing the 2.1.1 release
Back to the topic at hand. I'd like to check in XPathXMLFileModule before the release. I'll try to do that in the next few days. Carsten Ziegeler wrote: LOL - wow, that's really interesting to see - thanks for the information and I think this is a proof that even with a simple typo in the email the outcome can be useful! Ok, as you all have guessed already, I obviously meant 2.1.11 :) Carsten
Re: Preparing the 2.1.1 release
You can tell I'm from Los Angeles. When I first started to read this I couldn't figure it out because here it just doesn't take that long to fix a flat tire on a car. Of course, I then realized you meant you have to move to a new apartment. :-D Ralph Grzegorz Kossakowski wrote: Quick response: I have not forgotten about this and I even have given it a look but I have a lot of personal troubles these days, current one is that I need to change a flat and it turned out I have to do this before Christmas :-( I'm not sure when exactly I will find a new flat so I'm not sure if I manage to fix it for 2.1.11 but I promise to give a fix in any case...
Re: Preparing the 2.1.1 release
2.1.1? How many years ago was that? Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten
Re: Preparing the 2.1.1 release
I can't believe you went to the trouble to list all those Antonio - I was just trying to make a joke! I'm sure Carsten must have meant 2.1.11. Ralph Antonio Gallardo wrote: Ralph Goers escribió: 2.1.1? How many years ago was that? 4 years ago. Here is the full 2.1 series release dates: Version 2.1 (August 12 2003) Version 2.1.1 (September 05 2003) Version 2.1.2 (September 30 2003) Version 2.1.3 (November 13 2003) Version 2.1.4 (February 12 2004) Version 2.1.5.1 (July 9 2004) Version 2.1.6 (November 19 2004) Version 2.1.7 (March 23 2005) Version 2.1.8 (November 18 2005) Version 2.1.9 (April 7 2006) Version 2.1.10 (December 21 2006) Source: http://cocoon.apache.org/2.1/changes.html Best Regards, Antonio Gallardo. Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten
Re: [RT] RESTful web applications
Reinhard Poetz said: I agree with you but let me give you some reasoning that has lead to this misture: The problem is that developing really RESTful applications isn't entirely possible with current web browsers, e.g. you can't use other methods than POST and GET in your forms. Additionally, you will have a hard life if you want to compete with full-blown web app frameworks like JSF, Wicket, Tapestry or our own cForms because all of them introduce some kind of abstraction layer (= server-side forms) on top. On the one side this is handy, on the other side you fight against the nature of the web (HTTP) to some extend. The better a framework, the less problems you will face as web application developer. Isn't this pretty much what I said in an earlier post? One could argue now that if you use a framework that hides all those alleged limitations of HTTP fits your needs it doesn't matter whether you follow RESTful principles or not. However, IMO you lose a lot because if your web applications are implemented in a RESTful way, they are not only available for human users but also become useable by machines. I don't buy this. A machine wants a service, a human wants an interface it can interact with. The UI for the human may use that service, but in an MVC sense the service is providing access to the model, not the view. My second argument was that most of today's web applications are developed across two layers: One (bigger) part at the server's web-tier and one (smaller) part at the browser in the form of Javascript. Gee, that is a bit user-centric. Classic design also calls for a business tier and a data tier. If you decide to go the RESTful way and want to develop web applications that can compete with those developed based on one of those full-blown web frameworks, you will also need Javascript (event-handling, editing of several resources on one page, etc.). Probably, in comparison that's a bit more, but still manageable. In addition I expect that RESTful applications will be less complex. Why? Because all the complication is in the Javascript library? I still want to know how you are going to handle data that cannot or should not be stored in the user's browser? The argument that there isn't any (which you haven't made) just isn't the case. For me those are the reasons why I said that I have changed the camp and think that Stefano was right with his opinion that traditional web frameworks would become obsolete. But, in contrast to him, I think that Cocoon, which in some respect isn't 'traditional' at all, can become the ideal server-side counterpart for such RESTful web applications. No offense to Stefano, but I don't think he has ever worked at a bank. But yes, Cocoon should easily be able to handle this. Ralph
