Re: [RESULT][VOTE] Release Cocoon 2.1.12
Congrats for your first release! As an old timer I should have tested this 2.1 release, but I'm incredibly busy these days... I will do my best to test Cocoon 2.1.13 in... 2018 ? :-D Sylvain Le 19/03/13 17:46, Cédric Damioli a écrit : The vote for the 2.1.12 release passes with the 6 following +1 : - Thorsten Scherler - Robby Pelssers - Javier Puerto - David Crossley - Francesco Chicchiriccò - Cédric Damioli No others votes were cast. Code freeze is now over. I'll put the release files on the server and try to update web site (I'll certainly need help at some point for that). Thanks to all. Best regards, -- Sylvain Wallez - http://bluxte.net
Re: [DISCUSS] Releasing 2.1.12
Le 21/11/12 23:43, David Crossley a écrit : I am still around from the olden days and will try to help. However my time is very limited. Same for here! I would be happy to help where I can, but have limited time. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: HTML5 serializer
Le 06/01/12 15:48, Robby Pelssers a écrit :
Hi all,
I've been looking at how to add a HTML5 serializer to the project.
So far my investigations have led to add following code to
org.apache.cocoon.sax.component.XMLSerializer
public static XMLSerializer createHTML5Serializer() {
XMLSerializer serializer = new XMLSerializer();
serializer.setContentType(TEXT_HTML_UTF_8);
serializer.setDoctypePublic(XSLT-compat);
Looks like XSLT-compat has been changed to about:legacy-compat in
the latest HTML 5 specification.
See http://dev.w3.org/html5/spec/syntax.html#doctype-legacy-string
Sylvain
--
Sylvain Wallez - http://bluxte.net
Welcome Cédric Damioli and Robby Pelssers as Cocoon committers
Hi all, I am very happy to announce that the Cocoon PMC has voted Cédric Damioli and Robby Pelssers as new Cocoon committers, provided of course that they accept it. Also, once you have your commit rights, you are welcome to join the Cocoon PMC whose member have binding votes for releases and other project matters. Please read the instructions for committers and PMC members [1], first thing being to send a CLA if not already done, and suggest your preferred account name. Welcome on board guys! Sylvain [1] http://apache.org/dev/#committers -- Sylvain Wallez - http://bluxte.net
Re: Reuse of pipelines in java
Le 16/08/11 09:25, Steven Dolg a écrit : Am 14.08.2011 14:18, schrieb Sylvain Wallez: Le 12/08/11 21:08, Thorsten Scherler a écrit : Hi all, I am migrating a StAX development from a customer to c3 StAX, since the resulting code will be much more generic and understandable. In my case I need to process all files from different folders, parse them and invoke a second pipeline from the main pipe. Meaning I have one principal pipeline which I need to repeat x times. I started to create the pipeline and it works very nice, however I encounter some downsides with reusing the pipe. I found that you can execute a java based pipe exactly one time. There is no such method to reset the pipe. My plan was to inject the pipeline in my main code and then configure it on the Fly (reusing the same pipe on different files). Further there is as well no way to dynamically change the different components once added to the pipe. I mean PipelineStAXPipelineComponent pipeStAX = new NonCachingPipelineStAXPipelineComponent(); pipeStAX.addComponent(new XMLGenerator(input)); ... pipeStAX.setup(System.out); pipeStAX.execute(); Now my question is how people feel about: a) Making java based pipes resettable pipeStAX.reset() b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the component x in position i. a) What exactly should Pipeline.reset() do? (Besides calling reset on each component) And what should a component do during a reset? I think components can be configured/set up as often as you like. b) If you construct the components directly, can't you keep a reference to them and just call the setters/methods directly when needed? I guess I don't understand why the pipeline is not reusable in your case or what you need to reconfigure between the runs. Maybe you need x different pipelines for x different configurations? Although reset() can allow pipeline reuse, it won't solve the problem when you have multiple concurrent threads that could benefit from reusing the pipeline. Cocoon 2.x had component pools to allow reuse in a multithreaded context while avoiding the big cost of reparsing the component's configuration, but this proved to have a significant overhead. A solution that wouldn't require much changes in the current API would be to require pipelines and pipeline components to be Cloneable, so that you could build a pipeline instance once at startup and then clone it each time you need to use it. That would require component writers to be careful about cloneability though. Sylvain Pipelines are not thread-safe! Please read: I suggested to clone them, so that there is no need for them nor their components to be thread safe. You create a master pipeline that is never executed and then deep-clone it every time it needs to be processed. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Reuse of pipelines in java
Le 12/08/11 21:08, Thorsten Scherler a écrit : Hi all, I am migrating a StAX development from a customer to c3 StAX, since the resulting code will be much more generic and understandable. In my case I need to process all files from different folders, parse them and invoke a second pipeline from the main pipe. Meaning I have one principal pipeline which I need to repeat x times. I started to create the pipeline and it works very nice, however I encounter some downsides with reusing the pipe. I found that you can execute a java based pipe exactly one time. There is no such method to reset the pipe. My plan was to inject the pipeline in my main code and then configure it on the Fly (reusing the same pipe on different files). Further there is as well no way to dynamically change the different components once added to the pipe. I mean PipelineStAXPipelineComponent pipeStAX = new NonCachingPipelineStAXPipelineComponent(); pipeStAX.addComponent(new XMLGenerator(input)); ... pipeStAX.setup(System.out); pipeStAX.execute(); Now my question is how people feel about: a) Making java based pipes resettable pipeStAX.reset() b) Adding a method like pipeStAX.getComonponet(int i) to retrieve the component x in position i. Although reset() can allow pipeline reuse, it won't solve the problem when you have multiple concurrent threads that could benefit from reusing the pipeline. Cocoon 2.x had component pools to allow reuse in a multithreaded context while avoiding the big cost of reparsing the component's configuration, but this proved to have a significant overhead. A solution that wouldn't require much changes in the current API would be to require pipelines and pipeline components to be Cloneable, so that you could build a pipeline instance once at startup and then clone it each time you need to use it. That would require component writers to be careful about cloneability though. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [C3] Java version 1.6
Le 01/08/11 16:26, Nathaniel, Alfred a écrit : Hi all, C3 is still set to 1.5 as source and target version. Java5 is end of life since almost two years now. Is there any good reason not to go 1.6? Here's an additional one to the ones already given : StAX (javax.xml.stream) is included in 1.6, whereas it requires a separate implementation (e.g. Woodstox) in 1.5. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [proposal] cocoonstuff.org
Le 21/07/11 20:54, Reinhard Pötz a écrit : snip/ Nevertheless C3 already counts more than 20 subdirectories which is discouraging for people that want to get familiar with the code base. Especially if you don't need all the webapp/REST stuff you only need cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional. One could say that this problem can be solved with good documentation but the psychological barrier doesn't go away. Hmm... needing additional documentation is often the sign of some sort of problem. In this case, we may simply have too many modules. Why don't we have a cocoon-core module, so that people can know where to look at to understand what Cocoon is about? And this core module should not only be the cocoon-pipeline module, but should also include cocoon-util (3 classes!), cocoon-sax, cocoon-sitemap, cocoon-controller (3 classes again) and even cocoon-stax (Stax is provided in JDK 1.6). Also, along with providing more meat in the core, let's be opinionated and clearly say what Cocoon is about. For 2.2, the website says 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. Er... and what does this mean for a newcomer, particularly when Spring already has this huge amount of components and whose large number of interfaces and abstract classes could well be confused with separation of concerns ? What about a probably restrictive but clearer Cocoon is a versatile pipeline processing engine, particularly suited for XML processing and multi-format document publication, but also capable of processing binary content such as images. It provides integration modules with popular frameworks like Spring, Wicket and JAX-RS? With a bigger core and a clear tag line, we end up with a project that has 3 times less modules and where additional modules have a clear goal of integrating with a 3rd party library/framework (or providing a very specific feature, which often means also a 3rd party library). And more importantly, we have a core module that can actually *do* something and is not an almost empty shell of abstact concepts like cocoon-pipeline is. Sorry for this rant, but Cocoon has 2.x has grown into a toolbox for its committers (and I take my share in this), becoming more and more complex and abstract, being a different thing for each of its developers, and has lost its ability to be understood by newcomers. I think learning from this is particularly important if we want to rebuild a vibrant community around Cocoon 3.x Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [proposal] cocoonstuff.org
Le 28/07/11 15:28, Peter Hunsberger a écrit : What about a probably restrictive but clearer Cocoon is a versatile pipeline processing engine, particularly suited for XML processing and multi-format document publication, but also capable of processing binary content such as images. It provides integration modules with popular frameworks like Spring, Wicket and JAX-RS? Maybe not the best sentence in the world, but I like the intent here. Well, I'm neither a marketing guy nor a native english speaker ;-) Again I'd say +1 Thanks! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [proposal] cocoonstuff.org
Le 18/07/11 20:56, Reinhard Pötz a écrit : On 07/13/2011 09:30 AM, Steven Dolg wrote: We should take a look at introducing topic specific modules. I fear that the optional module turns into a giant clump of all things unrelated. Generally +1 to topic specific modules. As Steven already knows from Indoqa projects, I'm a fan of many small modules ;-) In regard to the still small C3 community (not in terms of people but rather in terms of SVN changes and mailing list activity) we should think about having a Cocoon Stuff project (analogous to Wicket Stuff) where everybody that is interested gets commit rights. This also clearly indicates what we as Apache Cocoon community consider being officially maintained. (BTW, the Wicket community is very restrictive in moving code from wicketstuff.org into the wicket-core codebase because of the mentioned maintenance reasons). The wicket folks had a vote between hosting their stuff project either at Github or at Apache-Extras (powered by Google Code). Github won and the result can be found at http://wicketstuff.org/ and https://github.com/wicketstuff/core But there is also a downside: - Cocoon release will become (slightly) more work in the future because two code bases have to be released - cocoonstuff.org releases are not ASF releases and we can't rely on the ASF litigation protection mechanisms anymore (which is also true for most opensource software out there) (NB: That is the reason why we need 3 +1 votes of PMC members before we can do a release and tag it with the Apache name) - that the transition has to be done: * contact the Apache Board about reserving the cocoonstuff.org domain * decide what goes to cocoonstuff.org and what remains at cocoon.apache.org * rename all packages accordingly * create a cocoonstuff-samples module * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for all cocoonstuff modules * decide about the release voting precedure * setup a cocoonstuff.org website (if we use Github we could also use it for hosting static websites) * find out how to get the Maven artifacts deployed to the central Maven repository * find a solution for continuous integration (Jenkins) and providing snapshot releases (Nexus?) But IMO there is also an additional benefit: Creating cocoonstuff would lower the barrier for contributions and could attract more people to get involved with C3. WDOT? Hmm... I definitely agree that modules specific to a 3rd party library or a JSR that's not included in the JDK are to be packaged as separate artifacts. As Steven rightfully points out, it's a real pain to download and package a huge load of libraries you don't need. And this what has been done in Cocoon since 2.0 with the large collection of blocks. Now hosting these modules away from apache.org is a different thing that has strong implications on community dynamics. The C3 community is slowly growing after having been almost dormant for months (years?), which is a very good thing, and I fear that a cocoonstuff.org would just harm this nascent effort by splitting the still brittle community. Also, a separate environment comes with additional time spent in administrative stuff (look at your long task list!) that could probably be used more wisely to build a stable C3. So if the purpose is to lower the barrier for contribution, then why not just having a contrib directory in SVN, clearly showing that these aren't core modules, but still under the oversight of the PMC and the ASF at large? Of course, managing Git pull requests would be more convenient than applying patches in Jira, but still, at this point, this is probably easier than having a completely separate infrastructure. My 0.02 cents. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [C3] XSLTTransformer cache
Le 21/06/11 18:08, Simone Tripodi a écrit : Hi again, that's not log4j but ant[1], it is easysmart enough that could be imported modified depending on our needs... Commons IO also has a file monitor that was written by Torsten : http://commons.apache.org/io/ There's also http://jnotify.sourceforge.net/ that uses native services such as inotify on Linux, which should be more efficient by avoiding polling, but I haven't tried it and it depends on native libraries. And we could make it generic in the way we can reuse the same policy also in all transformers that require an external resource to be load (i.e. the XSchema validator) That's a very good idea. Checking the file at each and every use can lead to a lot of requests to the filesystem on a loaded system, to check files that actually don't move that often. So doing it in the background adds some complexity but can allow hot reloading on a live system without hurting much performances. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: About copyright and translation
Le 16/02/11 07:56, Grégory Roche a écrit : Hello, this morning, I have put the Apache Licence 2.0 on my site. You can see the licence on the page : http://www.polymorphisme.com/serveurs/cocoon/licenceApache20.html and on the bottom of each page, I add the text : Copyright © 2011 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0. There is a difference between the license and the copyright. Your work can be licensed under the Apache License, but you keep the copyright. Only software and documentation distributed by the Apache Software Foundation is copyrighted by the Foundation. And to be more precise, each contributor keeps his individual copyright (in some countries like France you cannot give away your copyright), and this is the whole product that is copyrighted by the ASF. Your work however is a mix of original work (good job!) and translations of the original Cocoon documentation. For these translations, I think you did the right thing, by linking to the original documentation as a form of attribution. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: XMLSerializer.java why not implements CacheableProcessingComponent
Le 30/12/10 13:08, Thorsten Scherler a écrit :
Hi all,
I wonder is there a reason why nobody did
-public class XMLSerializer extends EncodingSerializer {
+public class XMLSerializer extends EncodingSerializer implements
CacheableProcessingComponent {
I am doing some caching enhancement for a client and using the profiler
I found out that my 100% cacheable page did not return 304. So I
stumbled upon the above.
When I make the XMLSerializer implementing CacheableProcessingComponent
the whole pipeline is returning 304 which I am looking for that the
status is for the response.
Without the above patch I always get a 200 since the serializer is not
cacheable hence the whole pipe.
Is there an obvious reason that I am not seeing why the serializer
should not be cacheable?
This is obviously an error, and the other serializer in
org.apache.cocoon.serialization.XMLSerializer is cacheable.
Sylvain
--
Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON-2289) [2.1] Backport FOPNGSerializer
[ https://issues.apache.org/jira/browse/COCOON-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1285#action_1285 ] Sylvain Wallez commented on COCOON-2289: There are still a huge number of projects using Cocoon 2.1, and products (this is Cédric's case) based on 2.1 where migrating to 2.2 would be a significant effort without much benefits. So a backport seems ok to me if some people need it, and even more if they actually have code ready and already running in production systems. [2.1] Backport FOPNGSerializer -- Key: COCOON-2289 URL: https://issues.apache.org/jira/browse/COCOON-2289 Project: Cocoon Issue Type: Improvement Components: Blocks: FOP Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Cocoon 2.1 still don't have official support for FOP 0.9x, while Cocoon 2.2 does This compatibility is only a matter of FOPSerializer (called FOPNGSerializer in the Cocoon 2.2 fop-ng block) I won't put a patch here because it would only be a copy of the FOPNGSerializer.java from Cocoon-2.2, but it would be great if someone could backport the fop-ng block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2286) Application does not start when the context path contains spaces
[ https://issues.apache.org/jira/browse/COCOON-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Wallez closed COCOON-2286. -- Resolution: Fixed Fix Version/s: 2.1.12-dev (Current SVN) Patch applied, with one minor modification: use specify the UTF-8 charset rather than relying on the JVM's default encoding Application does not start when the context path contains spaces Key: COCOON-2286 URL: https://issues.apache.org/jira/browse/COCOON-2286 Project: Cocoon Issue Type: Bug Components: Blocks: Serializers Affects Versions: 2.1.11 Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: CharsetFactory.java.patch When the CharsetFactory loads charsets from jar, the file path constructed from the jar URL may contains %20 or other encoded special characters. An exception is thrown when the jar file is being accessed : Root cause: java.io.FileNotFoundException: D:\cocoon%20build\WEB-INF\lib\cocoon-serializers-charsets-2.1.11.jar (Le chemin d'accès spécifié est introuvable) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:114) at java.util.zip.ZipFile.init(ZipFile.java:75) at org.apache.cocoon.components.serializers.encoding.CharsetFactory.loadCharsetsFromJar(CharsetFactory.java:130) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2286) Application does not start when the context path contains spaces
[ https://issues.apache.org/jira/browse/COCOON-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1285#action_1285 ] Sylvain Wallez commented on COCOON-2286: Very good point! Now the top line in changes.xml says Starting with 2.1.12 the minimum required Java version will be 1.4.2, so I guess we can safely use this method. Application does not start when the context path contains spaces Key: COCOON-2286 URL: https://issues.apache.org/jira/browse/COCOON-2286 Project: Cocoon Issue Type: Bug Components: Blocks: Serializers Affects Versions: 2.1.11 Reporter: Cédric Damioli Fix For: 2.1.12-dev (Current SVN) Attachments: CharsetFactory.java.patch When the CharsetFactory loads charsets from jar, the file path constructed from the jar URL may contains %20 or other encoded special characters. An exception is thrown when the jar file is being accessed : Root cause: java.io.FileNotFoundException: D:\cocoon%20build\WEB-INF\lib\cocoon-serializers-charsets-2.1.11.jar (Le chemin d'accès spécifié est introuvable) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:114) at java.util.zip.ZipFile.init(ZipFile.java:75) at org.apache.cocoon.components.serializers.encoding.CharsetFactory.loadCharsetsFromJar(CharsetFactory.java:130) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [2.1] Is Cocoon 2.1.x officially dead ?
David Crossley wrote: Bertrand Delacretaz wrote: Cédric Damioli wrote: ...I'm wondering if someone around here was still willing to maintain the Cocoon-2.1 branch ? If not, I volunteer to do the job, as this branch is important for us, and I don't want to have to fork it in our own repository I'm +1 on someone maintaining the 2.1 branch and cutting releases as needed. I don't use Cocoon anymore, but some of the projects that I created with 2.1.x a few years ago are still running very well and maintained, though more at the application level where they probably don't need changes to Cocoon itself. I think 2.1.x is stable enough for people who use it to stay on that version, so maintaining it makes at lot of sense. Are there any current committers willing to help maintain it? Yes, i will play a part. I can certainly help with the release process. I have tried on various occasions to apply some of the outstanding patches, but had difficulty. It would need the help of others. I still have a pretty good memory of Cocoon 2.1.x internals, and can help to review/apply patches. But I can't do any test on a real world application, so will need help from the user community before we can make a release. Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON3-54) LinkRewriterTransformer
[ https://issues.apache.org/jira/browse/COCOON3-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847808#action_12847808 ] Sylvain Wallez commented on COCOON3-54: --- The configuration of the rewriter needs to take into account element namespaces, so that you can deal with mixed namespace documents, e.g. xhtml and xlink or xinclude LinkRewriterTransformer --- Key: COCOON3-54 URL: https://issues.apache.org/jira/browse/COCOON3-54 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-sax Reporter: Francesco Chicchiriccò Assignee: Simone Tripodi Attachments: LinkRewriter.java, LinkRewriterTransformer.java, LinkRewritingException.java A LinkRewriterTransformer (like as the old one for Cocoon 2.1, see [1]) could be a very nice addendum to Cocoon 3. It could may even by an idea to have a LinkRewriterTransformerT, where T is the class performing the actual transformation on links. [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Type 'jsp' does not exist for 'map:generate'
Venura Kahawala wrote: Hi Jos, Thanks a lot for the reply But in the bellow link it says that Jsp can be used as a generator http://cocoon.apache.org/2.1/userdocs/jsp-generator.html Make sure you have included the cocoon-jsp-impl module in your configuration. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Exporting graphs to PDF
Simone Tripodi wrote: Hi, we included FOP in cocoon3 pipeline, in the optional module. The 3.0 is still an alpha, but you can take a look on it by downloading it from http://cocoon.apache.org//3.0/download.html If you want something to generate charts out of XML in various format (PNG, SVG, JPEG, GIF) for later inclusion in POF, you may take a look at Fins (http://www.lucamorandini.it/fins/index.html). Sounds *great* I'll integrate it on 3.0 pipeline :) Be careful: Fins uses JFreeChart, which is LGPL and a such cannot be added to the Apache source tree (http://www.jfree.org/jfreechart/). Best regards, happy new year!!! Same to you! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Simone Tripodi as new Cocoon committer
Reinhard Pötz wrote: I propose Simone Tripodi as a new Cocoon committer and PMC member. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [c3] Conditional GET
Reinhard Pötz wrote: When coming back to my original question about the implementation conditional get support based on cache keys, the important part of your comments is that you suggest using a _strong_ hash key. Is there any concrete implementation that you can recommend? (regarding speed and potential collisions and of course distributed under some 'friendly' license) I've been using 64-bit FNV hash [1] for a similar purpose (computing an ETag for a full response in dynamic pages, see [2]). It's fast and was designed to have a low collision rate even for small changes in the input data. There is a Java ASL-licensed implementation available at http://www.getopt.org/ I've also noticed a recent newcomer on the hash scene, MurmurHash, that seems to have even better speed and non-collision than FNV. There's also an implementation at getopt.org. Sylvain [1] http://en.wikipedia.org/wiki/Fowler_Noll_Vo_hash [2] http://bluxte.net/musings/2008/04/30/speeding-mobile-web-applications -- Sylvain Wallez - http://bluxte.net
Re: [c3] Conditional GET
Reinhard Pötz wrote: snip/ But let me broaden the picture: Based on our work from about two weeks ago, I created another aspect which implements the support for conditional GET requests and also takes care that a pipeline isn't executed unless it is really necessary. I was also able to fix all failing test cases. I created an issue that contains a patch: https://issues.apache.org/jira/browse/COCOON3-47 Additionally there is also another feature that I would like to add: The current patch only takes care of 'If-Modified-Since' requests. I also want to support 'If-None-Match' requests that are based on the 'ETag' response header. (see http://en.wikipedia.org/wiki/HTTP_ETag). Using ETag has the advantage that we could support conditional GET requests also in the case where we can't use a timestamp based approach (e.g. when using o.a.c.pipeline.caching.ParameterCacheKey) or to provide conditional GET support in REST controllers. As an ETag value we could use the hash code of a pipeline's cache key. I don't fully get the context of this conversation, but this last sentence triggered a question to me: how can we validate a cache entry with its _key_? Looking at the code, I see that CacheKey holds both the identifier information (the actual key) and the validity information. There is a naming issue here which leads to some confusion between key and key-and-validity that we can see it in the code: ExpiresCacheKey doesn't include the validity information in hashcode() and equals() whereas ParameterCacheKey does. What is the right contract? As a side note, both classes include the class' hashcode in the instance's hash code, which means hash codes will be different a every JVM restart, or across JVM instances in a cluster, and is likely to break persistent and distributed caches. That being said, I'm wondering if this aggregation of key and validity won't cause other kinds of problems with distributed cache implementations. For example, Java memcached clients serialize the cache key and use this result as the memcache key. If the key includes validity information, the memcache key will change every time the underlying data changes (e.g. a file's timestamp). At first sight, this can sound good as it means we will have a cache miss when the validity has changed, and will even avoid having to compare the validity of cached content. But this can have a desastrous impact on the cache efficiency in situations where you have some often requested content that changes frequently: the cache will quickly fill up with obsolete versions of this content under different key values, that will lead older content to be evicted, reducing the overall cache efficiency. Whereas a key that's only an indentifier will lead the entry to be _replaced_ and not a new one being added. So in the end, my feeling is that key and validity information really should be separated. Now going back to the ETag discussion, using the pipeline's cache key won't work IMHO because of the implementation of some key's hashcode() using only the identifier part of the key and not the validity. Confusion, I told you ;-) And BTW, what is the jmxGroupName property on CacheKey used for? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [c3] Conditional GET
Steven Dolg wrote: Sylvain Wallez schrieb: Reinhard Pötz wrote: snip/ But let me broaden the picture: Based on our work from about two weeks ago, I created another aspect which implements the support for conditional GET requests and also takes care that a pipeline isn't executed unless it is really necessary. I was also able to fix all failing test cases. I created an issue that contains a patch: https://issues.apache.org/jira/browse/COCOON3-47 Additionally there is also another feature that I would like to add: The current patch only takes care of 'If-Modified-Since' requests. I also want to support 'If-None-Match' requests that are based on the 'ETag' response header. (see http://en.wikipedia.org/wiki/HTTP_ETag). Using ETag has the advantage that we could support conditional GET requests also in the case where we can't use a timestamp based approach (e.g. when using o.a.c.pipeline.caching.ParameterCacheKey) or to provide conditional GET support in REST controllers. As an ETag value we could use the hash code of a pipeline's cache key. I don't fully get the context of this conversation, but this last sentence triggered a question to me: how can we validate a cache entry with its _key_? Looking at the code, I see that CacheKey holds both the identifier information (the actual key) and the validity information. There is a naming issue here which leads to some confusion between key and key-and-validity that we can see it in the code: ExpiresCacheKey doesn't include the validity information in hashcode() and equals() whereas ParameterCacheKey does. What is the right contract? I'm not sure I understand what you mean. The implementations of hashCode() in ExpiresCacheKey and ParameterCacheKey are as similar in both the code and actual behaviour as they can be. Neither of them performs any operations necessary to check their validity in the hashCode() or equals() methods. Hmm... ok, so parameter values are part of the key. When reading the code, and because of this mixing of validity and key (and lack of docs) I thought the parameter keys were defining the identity and their values were defining the validity. Your confusion might arrise from the point that ParameterCacheKey cannot become invalid because the same parameter value means always the same parameter value, there is no way this can become invalid (as opposed to a cache file contents which can become invalid when the file is changed, even if it is still the same file) So the isValid() method basically performs the equals check, since this is a required condition for being valid. (valid = equal not expired; since expired = false here: valid = equal). Ok. So with the definition of parameter keys and values being part of the identity, ExpiresCacheKey and ParameterCacheKey effectively behave consistenly. Now you'll understand that this becomes really confusing, and if there's not a very well defined contract for equals and hashcode (and even with that) there's a big opportunity for people to implement wrongly their CacheKey. The ExpiresCacheKey performs an additional check in its isValid() method, namely checking the expiresTimestamp. This is not done in either the hashcode() or equals() method. So here valid := equals not expired. This principle holds true for each and every CacheKey currently implemented (unless there is faulty implementation). And this is also the answer to your question: CacheKey contains information to check its validity, but this information is not used for identifying (iow, equals() and hashCode() methods) CacheKeys. Which means frequently invalidated CacheKeys will not fill the cache but instead overwrite each other. This is only true for cache implementations that rely on hashcode and equals(), i.e. that keep an index in a Map or a Set (ehcache does this for its DiskStore). But if you use a non-java cache or persistent store, you have no other solution than serializing the key and its validity information. This is for example the case with memcache which requires the key to be a String. And this is where the problem arises if you don't want or can't keep an in-memory index, e.g. because of size or distribution. As a side note, both classes include the class' hashcode in the instance's hash code, which means hash codes will be different a every JVM restart, or across JVM instances in a cluster, and is likely to break persistent and distributed caches. That is a good hint. We will want to look into that and amend things if necessary. Well, I would call it a bug that needs fixing, because it's basically equivalent to clearing persistent caches at every JVM restart or class reloading. That being said, I'm wondering if this aggregation of key and validity won't cause other kinds of problems with distributed cache implementations. For example, Java memcached clients serialize the cache key and use this result as the memcache key. If the key
Re: XInclude optimization
Simone Tripodi wrote: Hi Sylvain and Simone, thank you a lot, the suggestions you provided are all very very interesting, so I wonder now if it is possible to realize a processor able to use at the same time the Tika way when it recognizes some kind of paths, the XSL-on-the-fly for more complex cases. What do you think? As I suggested previously: first try to parse the XPath expression with Tika's parser, and if it fails because the expression doesn't match the subset it accepts, fall back to XSL-on-the-fly. Looking at Tika's parser [1], it looks like you'll have to overload the parse() method to fail hard by throwing an exception rather than returning Matcher.FAIL to be able to detect XPath features outside of the subset it accepts. Sylvain, I still haven't read the Tika documentation, can you just point me the related doc about this topic? There's no specific documentation on this particular feature, as its more an internal utility than a primary feature in Tika. Now the code is pretty straightforward. Simo, did you already give a try about the XSLT generation on the fly? The most basic operation I thought is generating the XSL string by a template, then pass it to the XSL parser, but I'm sure it could be implemented in a better way :P Sounds like the way to go, but you should cache the resulting template object to avoid recreating and reparsing the XSL at every request. The same applies to Tika matcher objects. Sylvain [1] https://svn.apache.org/repos/asf/lucene/tika/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath/XPathParser.java -- Sylvain Wallez - http://bluxte.net
Re: XInclude optimization
Simone Tripodi wrote: Hi Sylvain Sorry but I forgot to ask you a short question in the previous email: can the Tika code be imported/modified into Cocoon3? AFAIK it should be allowed, but I don't know the conditions under which it can be done. I don't really understand your question. Tika is an Apache project, so there's no license issue. Now if the question is about how, technically, to include Tika into Cocoon, I admit having no clue about that. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: XInclude optimization
Simone Gianni wrote: Hi Simone and Sylvain, aren't XSLT transformers already SAX/Xpath optimized? I mean, an XSLT containing an XPath expression and used in a SAX context, isn't already able to resolve the XPath while keeping buffering at the minimum possible? I can clearly remember that there has been a lot of work about this in Xalan and other XSLT engines, and also how a complex XPath expressions could change the performance of a transformation because of increased buffering. Xalan has an optimized implementation of the document tree [1], more efficient than the standard DOM for read-only and selection operations. Xalan has an incremental processing mode, but IIRC it's more about being able to produce some output before the whole document has been read rather than avoiding to build parts of the document tree. So it will allow for faster processing, but won't change memory consumption. In that case, maybe, instead of reinventing it, it should be possible to delegate the transformation (extraction of a fragment from the entire XML stream) to an XSLT processor. The simplest way could be to generate an XSLT on the fly :) .. the correct way would be to use the [Xalan|Saxon|any other] internal APIs to perform the XPath resolution. In both cases, it will be faster than transforming to DOM. Agree. It may be easier to produce a small XSL transformation from the XPointer expression than using Axiom. But still, for simple expressions, the pure streaming approach used by Tika would be way more efficient. Sylvain [1] http://xml.apache.org/xalan-j/dtm.html -- Sylvain Wallez - http://bluxte.net
Re: XInclude optimization
Simone Tripodi wrote: Hi all guys, I'm very sorry if I don't appear frequently on the ML but since April I've been working very hard for a customer client in Paris that don't let me some spare time to dedicate to OS projects. Don't be sorry. We all have our own jobs/interest/duties that have driven us away from Cocoon. Glad to see you back! I'm writing because I'm sure the XInclude transformer I submitted time ago could be optimized, so I'd like to ask you a little help :) The state of the art is that, when including an entire document, it is processed efficiently through SAX APIs; the problem comes when processing a document referenced by xinclude+xpointer, that forces the processor to extract a sub-document of the included. To perform this, I implemented a DOM parsing, then through XPath I extract the sub-document the processor has to be included, then navigating the elements will be converted to SAX events. As you noticed, this takes time, too much IMO, but I didn't find/don't know any better solution :( Since you experienced the stax, maybe you're able to suggest me a fast way to parse a document with xpath and invoke SAX events, so I'm able to provide you a much better - and faster, above all - solution. Any hint? Every suggestion will be very appreciated. The problem with XPath and XML streaming (be it SAX or StAX) is that XPath is a language that allows exploring the document tree in all directions and thus inherently expects having the whole document tree available, which is clearly not compatible with streaming. There are different approaches to solving this : - use a deferred loading DOM implementation, which buffers events only when it needs them to traverse the tree. Axiom [1] provides this IIRC, along with an XPath implementation. - restrain the XPointer expression to a subset of XPath that can easily be implemented on top of a stream. This means restricting selection only on the current element, its attribute and its ancestors. There's an implementation of this approach in Tika. The XInclude transformer can be smart enough to use the most efficient implementation for the given XPath expression, i.e. try to parse it with Tika's restricted subset, and fallback to something more costly, either Axiom or plain DOM. Sylvain [1] http://ws.apache.org/commons/axiom/ [2] https://svn.apache.org/repos/asf/lucene/tika/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath/ -- Sylvain Wallez - http://bluxte.net
Re: XInclude optimization
Simone Tripodi wrote: Hi Sylvain, thanks for your kind reply! I suspected the XPath limitations you explained very well, but deeply in my heart I was hoping to a solution I didn't know yet, for this reason I asked it :P :P I'll take a look at both the solutions, eve if the first sounds to me more compliant to the xpointer recommendation and at the same time closer with what I already did - and to older XInclude cocoon implementations. Axiom is what will give you the better compliance, but it is a relatively heavyweight solution compared to pure streaming. This is why I was suggesting to choose the actual xpath implementation according to the given XPath expression, since the Tika approach is really pure streaming. But this adds some complexity. Thank you very much for your hints, very well appreciated :) A bientot! Simone P.S. Offtopic: maybe I'm wrong, but I'm sure we met once in Tolouse, I was one of the Asemantics juniors involved in Joost :P That's right! I did not made the connection! This is a small world ;-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: XInclude optimization
Jos Snellings wrote: Hmmm, I guess the XPath expression is known before the parsing begins? I remember I have done a similar thing, where a chunk had to be isolated from a document that came by via a SAX stream, but here the xpath expression was something like: /element1/elemen...@id=somenumber]. Theorem: any XPath expression can be evaluated with a SAX filter. Proof? Do you know some exceptions? What about this one : //foo[bar[position() = 3]//baz], find all elements foo whose 3rd bar child has a baz descendent element. This requires to buffer the contents of every foo element to inspect their chidren sub-tree. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Unbalanced tags not triggering endTransformingElement in Transformer
Lochschmied, Alexander wrote: It’s resolved. My elements didn’t have the right namespace. I still don’t understand why there is a difference between source being a file VS other processing step though. Maybe I'm stating the obvious, but from a SAX point of view there's no difference between balanced and unbalanced elements. An element with no children elements nor embedded text is just a startElement() immediately followed by an endElement() for the same tag. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Listener in cocoon 2.2
Dominic Mitchell wrote: On Tue, Sep 29, 2009 at 10:38 AM, Thorsten Scherler thorsten.scherler@juntadeandalucia.es mailto:thorsten.scherler@juntadeandalucia.es wrote: Hi all, what is the best way to implement a Listener in cocoon 2.2? I our use case we have a listener uri that got dispatched by an external application to notify that some resources have changed and invalid our cache for that resource. The thing is that the uri do not have to/will not return anything in the body only in the request header. The current solution which was presented to us uses a custom generator which will not output anything. That just does not feel right. I did a small test with map:match pattern=notify map:act type=notify/ map:generate src=notify.xml/ map:serialize/ /map:match but that is just to make it work the normal cocoon way. The notify.xml is a dummy and I am not really thrilled about that neither. Using flow seems to be as well too much since we just want a simple listener that returns only http header. Last time I needed something like this I used the empty: source. Combined with a reader, that should do the track. map:match pattern=notify map:read src=empty: / /map:match This is untested — I can't remember if there are any quirks. Good trick. Now more than a source, which involves the SourceResolver machinery, a very simple stupid Reader can also do the trick. Or does the empty source already exist? map:match pattern=notify map:act type=notify map:read type=empty status-code=200/ /map:act /map:match Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
Ralph Goers wrote: 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. Hmm... true, but GPL virality only applies to distribution, i.e. when you ship in a same package a GPL'ed JDK and an application. When the end-user installs a Java application in an environment that already has a JDK, this user is the one doing the assembly, out of the control of the initial developer. The JDK APIs specification and the class file format specification aren't GPL'ed, meaning you can develop a non-GPL'ed application using any implementation of these specifications, even simple stubs that just make the compiler happy. Anyway, the rule of thumb for Dynnamitt is that adding a GPL'ed library to an Apache project is simply not possible. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
dynnamitt wrote: Out of curiosity : Why didn't you use XMLCalabash ? ( A pure Xproc impl in java ) Before any technical analysis of the product, the fact that it is GPL simply forbids its use in an Apache project. It also has an interesting (not!) feature [1] that collects anonymous usage data and send it who knows where for who knows what! Beyond privacy and security concerns, it also leads to some operational concerns. What happens if the home site is down, or if you have a busy website that floods it? Will it crash your own server? Sylvain [1] http://xmlcalabash.com/docs/phonehome.html -- Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
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/ Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Throw inside catch skips finally in Flowscript?
Jason von Nieda wrote:
Reposting this as I never got any kind of response. Are we the first
to run into this bug?
The version of Rhino used in the 2.1 branch is the initial
implementation of continutations, that was later included and refactored
into the main project at Mozilla.
So you should try to upgrade to the latest official release, this may
have been fixed. I don't remember though if a simple replacement of
rhino.jar works or if changes are required in the flowscript code. In
the latter case, have a look a the flowscript classes in 2.2, since it
uses the official Rhino.
Sylvain
On Wed, Apr 1, 2009 at 11:25 AM, Jason von Nieda
ja...@displayware.com mailto:ja...@displayware.com wrote:
Hi all, I ran into an issue that seems to be pretty serious and
I'm having a hard time finding any information about it.
In JavaScript Flowscript using Cocoon 2.1.11 and
Rhino rhino1.5r4-continuations-R26.jar it seems that throwing an
exception from within a catch block causes an associated finally
block to fail to execute. Example:
function test()
{
try {
// this line runs
Packages.java.lang.System.out.println(test1);
throw moof;
}
catch (e) {
// this line runs
Packages.java.lang.System.out.println(test2);
throw e;
}
finally {
// this line does not
Packages.java.lang.System.out.println(test3);
}
}
In the example above, if I remove the throw e; from the catch
block the finally block runs fine. Additionally, if instead of
using throw inside the catch I just run some code that causes an
exception to be thrown, the finally also does not run.
This seems fairly glaring to me, as it makes it impossible to use
a catch and a finally at the same time.
Can someone tell me if this is a known bug in Cocoon, or Rhino, or
something else and if there is some information about it? I'm
trying to decide how to proceed in fixing thousands of lines of Flow.
Thanks,
Jason von Nieda
--
Sylvain Wallez - http://bluxte.net
Re: [c3] Cocoon 3 Profiling student project
Andrew Savory wrote: Hi Reinhard, It's great that you're able to get students engaged, and to make it part of their curriculum. 2009/3/31 Reinhard Pötz reinh...@apache.org mailto:reinh...@apache.org yes, I guess it will take the students 2 - 4 weeks to really understand the problem and possible solutions. Then they will keep this list posted with their insights, proposals and patches and everybody will get a chance to comment. The plan is to work in 2 week iterations until the end of June. This will mean about 4 - 6 public iterations. If I might make a suggestion: understanding the problem and possible solutions is where the cocoon developer community can really help as well. It's how many of us got started here, with initial discussions that ended up with us having the confidence to contribute code. It also stimulates the community, providing diversity and discussion that might trigger other work as well. +1. Most of us started by asking dumb questions here. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] C3: Cleaning up SAX module
Carsten Ziegeler wrote: Hi, I think we can reduce the number of interfaces in the SAX module by just removing XMLProducer and XMLConsumer. XMLProducer is just a marker interface combining Producer and SAXPipelineComponent, so we can just remove it. XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Yup, it's easier to wrap separate ContentHander and LexicalHandler objects into a simple wrapper implementing both interfaces rather than having to deal with a Cocoon-specific XMLConsumer everywhere. Now we should also consider javax.xml.sax.SAXResult that holds a ContentHandler and an optional LexicalHandler, and has an interesting SystemId property that could be used to propagate a base URI from one component to the next one without relying on an external resolver context. And the fact that SAXResult _holds_ the handlers rather than implementing the interfaces can in many cases avoid a level of wrapping as the one mentioned above. But the properties in SAXResult are mutable and the javadocs don't specify when these properties can change, i.e. if a producer should call getHandler() every time it needs to produce events of if the value can be kept for the whole stream of events, even if I think the second case is the most often used. So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] C3: Cleaning up SAX module
Carsten Ziegeler wrote: Sylvain Wallez wrote: So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Yes, it seems better than relying on a not clearly specified assumption Absolutely! (btw, if the sax result just has a content handler, this should be tried to be casted to a lexical handler as well, so we are in good company) Indeed ;-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [COCOON3] XSLTTransformer optimization and reusability
Simone Tripodi wrote: Hi Reinhard, I'm sorry I was not very clear, as reloader I mean a sort of XSLT watchdog that reload it when it's changed - it's a feature already present in oldest Cocoon's version, Sylvain spoke about it in the Jira issue There are two ways you can consider to reload stylesheets: check if it's up to date when it is used, and reload if necessary, or have a background watchdog that triggers reload. The first solution is the simplest one to implement, but has two drawbacks: - the first user request that uses the modified stylesheet pays the cost of reloading. Probably not an issue in production systems though, since XSLTs are not supposed to change often and are usually fast to load. - on a busy system, it puts a high load on the filesystem to check if the file has changed. This is solved by ensuring the file is checked only once for a given period of time (e.g. 1 second) regardless of the number of uses of the stylesheet that happen during this period. This is achieved by using a DelayedValidity object that wraps the actual source validity. Sylvain [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/source/impl/validity/DelayedValidity.java -- Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON3-6) The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized
[ https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12642190#action_12642190 ] Sylvain Wallez commented on COCOON3-6: -- Have a look at http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java and all its dependencies. The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized - Key: COCOON3-6 URL: https://issues.apache.org/jira/browse/COCOON3-6 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: XSLTTransformerOptimization.patch Every time the XSLTTransformer#setXMLConsumer method is called, the XSLT is parsed reading the URL source and used to create the javax.xml.transform.sax.TransformerHandler: to be more clear [...] XSLTTransformer xsltTransformer = new XSLTTransformer(getClass().getResource(myXSLT.xsl)); Pipeline pipeline1 = new NonCachingPipeline(); pipeline1.addComponent(new StringGenerator(xy//x)); pipeline1.addComponent(xsltTransformer); pipeline1.addComponent(new XMLSerializer()); pipeline1.setup(System.out); pipeline1.execute(); Pipeline pipeline2 = new NonCachingPipeline(); pipeline2.addComponent(new StringGenerator(zw//z)); pipeline2.addComponent(xsltTransformer); == the URL pointed by getClass().getResource(myXSLT.xsl) will be parsed again!!! pipeline2.addComponent(new XMLSerializer()); pipeline2.setup(System.out); pipeline2.execute(); As a quick solution we can store the Template to build the transformer handler objects in a static hashmap, but in the future we should introduce stores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-6) The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized
[ https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641831#action_12641831 ] Sylvain Wallez commented on COCOON3-6: -- This feature has been available in Cocoon for ages, storing Template objects in a LRU cache, and reloading stylesheets as needed when they have changed. Writing a new Cocoon is fine, but it should learn from the old one and reuse some of it. The org.apache.cocoon.pipeline.component.sax.XSLTTransformer can be optimized - Key: COCOON3-6 URL: https://issues.apache.org/jira/browse/COCOON3-6 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Cocoon Developers Team Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: XSLTTransformerOptimization.patch Every time the XSLTTransformer#setXMLConsumer method is called, the XSLT is parsed reading the URL source and used to create the javax.xml.transform.sax.TransformerHandler: to be more clear [...] XSLTTransformer xsltTransformer = new XSLTTransformer(getClass().getResource(myXSLT.xsl)); Pipeline pipeline1 = new NonCachingPipeline(); pipeline1.addComponent(new StringGenerator(xy//x)); pipeline1.addComponent(xsltTransformer); pipeline1.addComponent(new XMLSerializer()); pipeline1.setup(System.out); pipeline1.execute(); Pipeline pipeline2 = new NonCachingPipeline(); pipeline2.addComponent(new StringGenerator(zw//z)); pipeline2.addComponent(xsltTransformer); == the URL pointed by getClass().getResource(myXSLT.xsl) will be parsed again!!! pipeline2.addComponent(new XMLSerializer()); pipeline2.setup(System.out); pipeline2.execute(); As a quick solution we can store the Template to build the transformer handler objects in a static hashmap, but in the future we should introduce stores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New Spring Maintenance policy
Leszek Gawron wrote: Sylvain Wallez wrote: Joerg Heinicke wrote: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Wow, that's even worse... That move is probably plain stupid. Rod Johnson states that the full source tree will still be available - there will be simply no public releases after 3 months and no svn tags to build that release yourself. You will only be able to build snapshots (better said internal releases) to address the issues you encounter. Yet again: plain stupid. Every open source project will have to track it's spring version by its own. How will the project be able to report issues if 99% of the world will be using snapshots? My spring version r144554 shows some problem? Clearly this is very short sighted. There's an easy way the OSS community can react to that: create an OpenSpring.org website that will provide official open source maintenance releases from well-known revisions of the SpringSource SCM. That way, people will be able to use e.g. openspring 2.4.8 which will actually be springsource r144554 It is even more insulting to the comunity stating that it is too costly for SpringSource to do 'mvn deploy' from time to time. It's just a marketing version of Buy a damn subscription!. There's an quick and easy way to force users to subscription: just make major releases less frequent. If you haven't read on TSS: Although the prices are not publicly known someone stated that yearly subscription is something about $16 000... Ouch. Spring was born as a lightweight and open source alternative to big and costly J2EE containers. It's now as big and costly (and as bloated?) as a J2EE container... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: New Spring Maintenance policy
Joerg Heinicke wrote: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Wow, that's even worse... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: New Spring Maintenance policy
Joerg Heinicke wrote: On 23.09.2008 22:43, Peter Hunsberger wrote: As the number of versions of Spring used in production grows, it is impossible for us to provide free maintenance for multiple releases and perform backports of issues. Doing so would unfairly subsidize conservative customers who want to remain on a previous version, at the cost of the open source community. The reasoning is totally awkward. Nobody questions discontinuing support for old major releases. But how does the above justify not providing patch releases after 3 month of a major release? [1] They are doing those releases anyway. The last sentence above is purely a joke. At the end the new maintenance policy is a means to push people into the enterprise support program. They are absolutely free to do so, but they should admit it not talk crap. Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Sylvain Wallez pisze: I would say the contrary. Let's not forget that most of our users aren't hard-core developers (they love Cocoon because they can do complex stuff without programming) and they aren't used to this odd/even versioning scheme that comes from the Linux kernel. Rather than that, it seems to me that most of the normal (i.e. non hard-core hacker) people consider a version without any beta, milestone or other suffix as an official stable release. A well-known example is Firefox that goes through a series of milestones, beta and RC version before releasing a stable version with the same number. Eclipse does the same. Yes, that makes sense. I also wonder how beta, RC, etc. releases can be more confusing that odd/even versioning. Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on vacation, but I really think this is too early. Cocoon 2.2 is just out and we announce a 3.0. This will most probably lead people to consider 2.2 as a transition to 3.0 and just not use it, and thus just look elsewhere. Provided that one documents our thoughts on 2.2 and 3.0 clearly I don't think there will be that much of confusion. Actually, I think it's a high time for us to define official document that explains our rules for giving artifacts version numbers. WDYT? Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. I can't say what problems there are _now_ since I don't build Cocoon anymore. Hopefully it works now, and I was referring to the past: when the move to Maven was started, the 2.2 build was mostly broken for months, which drained an incredible amount of energy away from the project, either because people got discouraged by this broken build (e.g. me), or because they invested their volunteer time in understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon. I'm glad it seems to work now, but the amount of energy needed to setup and maintain this build system (remember, it's _just_ a build system) has been astronomical. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. It's very nice to see people using 2.2, but I have the impression that most of the 2.2-related questions are related to maven-isms, artifacts, poms, etc. Without wanting to sound harsh, I'm wondering whether this community has learned to live over time with some sort of chronic disease, and is so used to it now that it doesn't even realize that life could be easier without it. Note that I said could and not would since ultimately the people-that-do decide what they prefer. And yes I'm a retired old-timer here, but I still care for this community where I learned so much. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my response. The last statement was not really needed. I'm sorry about that, Sylvain. No worries. I was actually trying to understand what you really meant :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Reinhard Pötz wrote: Sylvain Wallez wrote: 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. I would say the contrary. Let's not forget that most of our users aren't hard-core developers (they love Cocoon because they can do complex stuff without programming) and they aren't used to this odd/even versioning scheme that comes from the Linux kernel. Rather than that, it seems to me that most of the normal (i.e. non hard-core hacker) people consider a version without any beta, milestone or other suffix as an official stable release. A well-known example is Firefox that goes through a series of milestones, beta and RC version before releasing a stable version with the same number. Eclipse does the same. I don't have a strong opinion on this, except that I don't think that the term milestone doesn't fit very well for us because this would imply that we have like e.g. Eclipse a well-defined roadmap. And as we all know, that's simply not the case. Well, although there's no formal roadmaps, there are big features that more or less define it, isn't it? I'm also fine with 3.0-alpha-1, etc. and, see the reasons below, it's probably better to change the proposal into this direction. Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on vacation, but I really think this is too early. Cocoon 2.2 is just out and we announce a 3.0. This will most probably lead people to consider 2.2 as a transition to 3.0 and just not use it, and thus just look elsewhere. Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. We had three possible routes for Corona: 1) Develop Corona outside of the Cocoon project (e.g. Google, Sourceforge, etc.) 2) Find some alternative name and release it under this codename. 3) Release it as Cocoon 3.0-alpha-x 1) would have been really dangerous IMO. What would people have thought if the former PMC chair created an alternative project that is a reimplementation of Cocoon outside of the oversight of the Cocoon PMC. And that just a few months after his resignation. I totally agree with this, and Apache has the necessary rules and infrastructure to host experiments/rewrites/revolutions under the project's umbrella. 2) Many people advised not to invent another codename. Also the name finding game wasn't really successful. Personally I'm not willing to invest any more time into this. I don't think there's even a need to play the name game: if the experiment/rewrite/revolution is successful, it just takes over the main branch (e.g. Catalina that has replaced Tomcat) and otherwise it just dies and vanishes. 3) Releasing 3.0 comes with the risk that 3.0 never takes off and doesn't attract a broader developer and user community. But as long as we only release alpha software, we can even do a re-rewrite. Not sure I follow you here, and how 3.0 or any other name prevents a rewrite as long as there hasn't been any stable release. Now if there is an ongoing effort on something named 3.0 and suddenly this thing is rewritten, this is likely to be interpreted by the community as we don't really know where we're going which not a good thing. Regarding your too early announced argument, I'm not so pessimistic. Most people very well understand the difference between production quality and alpha software and that alpha software is no guarantee for anything (time, quality/stability, community). Addtionally we will add warnings to all download pages, READMEs and also adding alpha helps. Also other projects demonstrate that having an alpha branch doesn't make most people wait for the final release of the alpha branch (see Tomcat, Jetty, Maven, httpd, etc.). And if you have time to wait, I don't think that you really have to solve a problem. I hope you're right. Additionally we have taken care that Cocoon 2.2 can be run in parallel with Cocoon 3.0 in the same web application and they can event communicate via the Servlet-Service framework with each other. Great! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Grzegorz Kossakowski wrote: Sylvain Wallez pisze: I can't say what problems there are _now_ since I don't build Cocoon anymore. Hopefully it works now, and I was referring to the past: when the move to Maven was started, the 2.2 build was mostly broken for months, which drained an incredible amount of energy away from the project, either because people got discouraged by this broken build (e.g. me), or because they invested their volunteer time in understanding Maven (e.g. Jorg Heymans) rather than developing Cocoon. I'm glad it seems to work now, but the amount of energy needed to setup and maintain this build system (remember, it's _just_ a build system) has been astronomical. I've been working with Maven (mainly when working with Cocoon) for more than year and I can agree on main point of Maven critics that Maven is flawed. My personal opinion is that basic ideas behind Maven are correct but implementation is totally broken. Or at least it was at the beginning because now, thanks to many eye balls, it seems to improve from release to release. I was wondering many times if there is any other choice for us. Given the amount energy we've put into mavenization process any switch is impossible so such discussion could be only theoretical. Still I would enjoy reading about some alternatives because this could put my (and probably others) thinking into right direction thus, eventually improving our existing infrastructure. This isn't theoretical at all. Use Ant+Ivy (http://ant.apache.org/ivy/) and you have something that doesn't rely on undocumented declarative black magic (the various plugins you add to your pom.xml), doesn't require you to write your own plugins (or tasks as they're called in Ant) and gives you line-precise error reporting when something goes wrong. There is one statement that I don't agree: Maven is not just a build system. If it was only a build system I would be the first one to propose dropping Maven completely because of its implementation. For me, Maven is the whole ecosystem which consists of good practices when it comes to your project's structure, Maven repository (the killer feature IMHO) and integration with so many systems acting around basic build process. Ivy for your artifacts management. It does it well, and can use Maven repositories. I've been using it happily for more than 2 years now on rather big projects (after having banged my head on Maven). What I would prefer is to take a lesson from our past experience but still focus on the future. I strongly believe that we have reached this stage when people can happily focus on developing Cocoon and not on developing Cocoon's infrastructure thus I would like to invite all old-timers to join our forces and provide the best of Cocoon experience ever. I strongly believe we have all foundations needed for that now. And this leads to another question, which Reinhard outlined in his latest blog post, and Stefano did years ago: what's the purpose of Cocoon in today's technology landscape? It used to be a great you can do everything with it solution, but these days are over. There are some very nice webapp component frameworks like Wicket or GWT, there are ESBs that do pipelined transformations like Mule or ServiceMix, and XML is no more the only mainstream interchange language with the success of JSON and the emergence of binary formats like Thrift or Google Buffers. Cocoon therefore has to be rethought as a toolbox for those domains where it has no equivalent, and find new domains where it can innovate, and Corona (or whatever its name) certainly goes in the right direction. Pipelines are among the existing distinctive features of Cocoon, and also REST-ish pattern matching although many frameworks are now REST-friendly. It's very nice to see people using 2.2, but I have the impression that most of the 2.2-related questions are related to maven-isms, artifacts, poms, etc. Without wanting to sound harsh, I'm wondering whether this community has learned to live over time with some sort of chronic disease, and is so used to it now that it doesn't even realize that life could be easier without it. Most of these questions come from the confusion about splitting up Cocoon into smaller pieces. And even more questions come from the fact that people starting with 2.2 are still trying to build it themselves because that was done in 2.1. If you use released versions then you will have no problem with dependencies, missing artifacts, etc. When you checkout trunk and try to build it then I would say that it should be no surprise that sometimes you get into troubles, right? The build should fail only if there are some bugs in Cocoon's code (compilation issues or failed tests) or if some artifacts are missing from your cache and remote repositories aren't available (BTW this what just happened to me: there's a compilation failure in cocoon-core). I would really
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Ralph Goers wrote: 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. That is exactly what I wanted to point out with the Maven sucked too much energy from Cocoon argument: I don't want and shouldn't have to become a committer on the build system as a necessary preliminary to doing usefull stuff on Cocoon. 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. Most of the Maven plugins can be rewritten in a couple of Ant lines. Also, it is possible to have common reusable Ant build files that avoid rewriting everything from scratch every time. Now it's true that no community effort has taken place to provide a distribution of such standard reusable Ant files. Maybe people did not felt the urge to do so because Ant files to build simple artifacts are so straightforward. 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. I now this is work in progress. But not self-updating should be the default rather than being an intial feature that can be disabled by specifying the exact version of each and every Maven plugin you want a fixed-version of (and how do I know which version I want?) Now I'll shut up since most people here seem to be happy with Maven. I'm not, let's move on to other debates. Sylvain -- Sylvain Wallez - http://bluxte.net
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. I would say the contrary. Let's not forget that most of our users aren't hard-core developers (they love Cocoon because they can do complex stuff without programming) and they aren't used to this odd/even versioning scheme that comes from the Linux kernel. Rather than that, it seems to me that most of the normal (i.e. non hard-core hacker) people consider a version without any beta, milestone or other suffix as an official stable release. A well-known example is Firefox that goes through a series of milestones, beta and RC version before releasing a stable version with the same number. Eclipse does the same. Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on vacation, but I really think this is too early. Cocoon 2.2 is just out and we announce a 3.0. This will most probably lead people to consider 2.2 as a transition to 3.0 and just not use it, and thus just look elsewhere. Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. My 0.02 euros. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Corona] PIpeline API
Carsten Ziegeler wrote: Peter Hunsberger wrote: On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote: Are you talking about passing the input parameters as parameters of the setup() method? void setup(MapString, Object inputParameters) I'd be fine by this. I hate seeing Maps used as dumping grounds for randomly typed objects. Could you use something that gives a little more strong typing? Perhaps more like a ServletContext though I don't think I'd go that far in this case? I agree that strong typing would be great - but the pipeline api does not define any concrete key/object for the map. So this is use-case specific. Therefore I think a map is the best we can come up. Trying to catch up on this discussion. What parameters are we talking about exactly? Are these pipeline parameters? What's the need for that? Can't we just give the parameters they need individually to every pipeline component, thus allowing per-component strongly typed and well defined contracts? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Plugging that big XSP shaped hole
Kamal wrote:
Hi,
As has probably been discussed numerous times on this list, XSPs are
deprecated (or at least perceived to be, I won't get into the
philosophical discussion ) and flowscript + JXTemplates are the new
deal. As I (as well as others) have said in the past, I don't think
that this is an adequate solution. In a previous email, I stated three
issues that I think stop the flowscript + JXTemplate from adequately
replacing XSPs. I will repeat them here:
1. It leads to an explosion in pipelines. Instead of one pipeline, you
now have 2 (at least) instead of the one you get with XSPs.
2. There is so much that isn't easily ported to a JXTemplates +
flowscript environment. For example, there is no analogy to xsp:element.
3. No analogous functionality to the esql logicsheet. You basically
have to create your own and for simple queries, this can quickly
become a hassle.
I will add one more issue:
4. No replacement for xsp-action.
I have fixed the issue of there being no jx:element (though, I suspect
there are other things that XSPs give that Flowscript + JXtemplates do
not give us), and I am not going to even try to tackle issue (3).
However, I would like to take a stab at issue (4) and propose a
solution for issue (1).
Firstly, the replacement for xsp-action. I was thinking about a
Javascript Action. The basic idea is that you pass in as the src a
javascript file. This javascript file will contain a code that returns
an object, this object contains a set of variables that the action
then makes available to the sitemap (similar to flow attributes). I
think the basic idea is sound. I am thinking some of the code that is
available in the forms block [1] could be employed here. I am not too
sure how you stop people from doing silly things (such as allowing
people to define objects and functions rather than primitives) but I
suspect that flowscript deals with this issue.
Now that I bought up Flowscript, I guess I should answer why I feel
Flowscript does not replace XSP-action. In my case, I have an XSP
action that checks the database for a particular record. If this
record exists, it gets a column, which contains a directory for a set
of XSLT, this location is then used to select a particular XSLT for a
transformation. This action is used everywhere, the idea of
replicating this functionality in Flowscript sounds very messy. Also,
I don't believe Cocoon makes for a great Java framework and I believe
that your average user shouldn't have to know the gory details of
Cocoon to do simple things.
Please tell me if all of this sounds naive.
As the author of xsp-action, I have to say it was an ugly hack, meant
primarily for speeding up development cycles at a time when we did not
have flowscript nor hot code replace in Java debuggers.
Now your use case is right, and I agree that flowscript is overly
complex when all you need is a simple action that prepares some data or
defines routing in a pipeline as in your use case. And we talked several
times in the past about a JS-action that would sort of unify flowscript
and actions, but IIRC it was never implemented.
I will leave up to a vote as to whether this change should go through.
If we have a majority, I am happy to work on this action if someone is
willing to give me some guidance.
As for (1), I will reiterate what I said in a previous email[2]:
I was wondering if anyone has thought of creating an extension to
JXTemplates to support a new style of template. One where you can
specify a javascript/Java/Ruby/whatever at the top and the
presentation after that. For example, something like this:
Template
Flow
Javascript
return({content : 123});
/Javascript
/Flow
Presentation
some_content
jx:out value=${content}/
/some_content
/Presentation
/Template
This would return:
some_content123/some_content
Is this possible? In some cases, I think this will be a neat solution
as you still have a clear separation between logic and presentation,
but you don't need to open three separate files to see what is going
on. Also, I don't see this as a replacement for flowscript, just
another tool in the toolbox that is Cocoon.
Considering the lack of a response to this functionality, I suspect
that it isn't doable or it is viewed as undesirable. If it is either
of these, can I please get an explanation? I suspect is a fairly big
task and it is probably something (at this point in time) I am not
capable of doing. That said, if no one has an objection to the
functionality and I can get some guidance, I am happy to look at
implementing it.
Hmm... This proposal is clearly mixing logic and presentation, which is
what Cocoon is all against! And this is one for the reasons that led to
deprecate XSP that opens the door to writing all application logic in
xsp:logic elements.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Plugging that big XSP shaped hole
Kamal wrote: As the author of xsp-action, I have to say it was an ugly hack, meant primarily for speeding up development cycles at a time when we did not have flowscript nor hot code replace in Java debuggers. Now your use case is right, and I agree that flowscript is overly complex when all you need is a simple action that prepares some data or defines routing in a pipeline as in your use case. And we talked several times in the past about a JS-action that would sort of unify flowscript and actions, but IIRC it was never implemented. Was it not implemented because it was deemed too difficult or because no one had the time to do it? I don't think it's a very complex task, and a lot can be borrowed from the existing flowscript code. This is even needed, so that from a js-action we can access the global variables and the view data (also called biz data) used in flowscript. The js-action must be able to work independently, but also integrate nicely with flowscript for scenarios where it is needed. So it's a matter of time, or itch to scratch. Seems you have this itch :-) Note that there is a BSFAction that can be used for actions using any of the scripting languages supported by BSF (including JS), but it isn't closely integrated with the flowscript data. Is this possible? In some cases, I think this will be a neat solution as you still have a clear separation between logic and presentation, but you don't need to open three separate files to see what is going on. Also, I don't see this as a replacement for flowscript, just another tool in the toolbox that is Cocoon. Considering the lack of a response to this functionality, I suspect that it isn't doable or it is viewed as undesirable. If it is either of these, can I please get an explanation? I suspect is a fairly big task and it is probably something (at this point in time) I am not capable of doing. That said, if no one has an objection to the functionality and I can get some guidance, I am happy to look at implementing it. Hmm... This proposal is clearly mixing logic and presentation, which is what Cocoon is all against! And this is one for the reasons that led to deprecate XSP that opens the door to writing all application logic in xsp:logic elements. I am definitely in agreement with you about how Cocoon should be against mixing of logic and presentation. In fact, I would go further and say that is goal of XML. However, I disagree with your assertion that my proposal is a mixing of logic and presentation. It has a clear separation of logic and presentation, this just done in one file. The idea would be that you would have one and only one Flow section and one and only one presentation section. With Javascript defined in the Flow section, you would have the ability to dynamically setup organic objects to do what was required in the Presentation section. The problem with XSPs (IMHO) was not that XSPs had logic and presentation in the same file, it was the intermixing of logic and presentation (not to mention the ugly mixing of java and XML). My proposal does not have this problem as if enforces the separation. Also, I am concerned that in deprecating XSPs we have replaced one set of problems (the intermixing of logic and presentation) with problems that are almost as big - a lack of transparency and sitemap bloat. The sitemap bloat I have talked about. What I mean by lack of transparency is best described with an example. If I find a bug with a particular URL, in the past, all I had to do was find the appropriate pipeline and all the information and files I needed to debug the problem would have been there. Now, in the flowscript world, I would have to find the appropriate pipeline. This would have a function call. I would then have to search through all my flowscripts to find that function call, after which I would have to look through the function to find out where the send page is. When this is done, I go find that pipeline and then open up the JX Template. Phew, that is a lot of work just to see what is going on. It is no longer transparent as to what is going on. In cases where there is complex logic associated with specifying what route to take flowscripts are necessary (not to mention the easiest solution), but I don't see the need for the overhead in the case when you want to, for example, query a database, process the results and hand off the resultant object to a JXTemplate to format the content. I see your point, and the pipeline stacktraces only help when things go really wrong. Now the js-action would make things easier, don't you think? Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Closed: (COCOON-2208) Race condition in AbstractCachingProcessingPipeline causes threads to hang.
[
https://issues.apache.org/jira/browse/COCOON-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Wallez closed COCOON-2208.
--
Resolution: Duplicate
Yes, it's the same as COCOON-1985. Sorry for the noise...
Race condition in AbstractCachingProcessingPipeline causes threads to hang.
---
Key: COCOON-2208
URL: https://issues.apache.org/jira/browse/COCOON-2208
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: Sylvain Wallez
Priority: Blocker
There's a race condition in AbstractCachingProcessingPipeline.waitForLock() :
if lock is not null, there is a possibility that the thread that created
the lock releases it before the current thread starts waiting on it (see
below). When this happens, the thread waits forever since no thread will ever
call notify() on the lock.
The very bad effect is that this progressively blocks the entire thread pool
of the servlet engine, which ends up rejecting new incoming connections.
And BTW, calling containsKey() just before get() unneedingly doubles the
number of lookups.
{noformat}
protected boolean waitForLock(Object key) {
if(transientStore != null) {
Object lock = null;
synchronized(transientStore) {
String lockKey = PIPELOCK_PREFIX+key;
if(transientStore.containsKey(lockKey)) {
// cache content is currently being generated, wait for
other thread
lock = transientStore.get(lockKey);
}
}
// START OF RACE CONDITION ZONE
if(lock != null) {
try {
// become owner of monitor
synchronized(lock) {
// END OF RACE CONDITION ZONE
lock.wait();
}
} catch (InterruptedException e) {
if(getLogger().isDebugEnabled()) {
getLogger().debug(Got interrupted
waiting for other pipeline to finish processing, retrying...,e);
}
return false;
}
if(getLogger().isDebugEnabled()) {
getLogger().debug(Other pipeline finished
processing, retrying to get cached response.);
}
return false;
}
}
return true;
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2208) Race condition in AbstractCachingProcessingPipeline causes threads to hang.
Race condition in AbstractCachingProcessingPipeline causes threads to hang.
---
Key: COCOON-2208
URL: https://issues.apache.org/jira/browse/COCOON-2208
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.11
Reporter: Sylvain Wallez
Priority: Blocker
There's a race condition in AbstractCachingProcessingPipeline.waitForLock() :
if lock is not null, there is a possibility that the thread that created the
lock releases it before the current thread starts waiting on it (see below).
When this happens, the thread waits forever since no thread will ever call
notify() on the lock.
The very bad effect is that this progressively blocks the entire thread pool of
the servlet engine, which ends up rejecting new incoming connections.
And BTW, calling containsKey() just before get() unneedingly doubles the number
of lookups.
{noformat}
protected boolean waitForLock(Object key) {
if(transientStore != null) {
Object lock = null;
synchronized(transientStore) {
String lockKey = PIPELOCK_PREFIX+key;
if(transientStore.containsKey(lockKey)) {
// cache content is currently being generated, wait for
other thread
lock = transientStore.get(lockKey);
}
}
// START OF RACE CONDITION ZONE
if(lock != null) {
try {
// become owner of monitor
synchronized(lock) {
// END OF RACE CONDITION ZONE
lock.wait();
}
} catch (InterruptedException e) {
if(getLogger().isDebugEnabled()) {
getLogger().debug(Got interrupted
waiting for other pipeline to finish processing, retrying...,e);
}
return false;
}
if(getLogger().isDebugEnabled()) {
getLogger().debug(Other pipeline finished
processing, retrying to get cached response.);
}
return false;
}
}
return true;
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: BufferedOutputStream
Joerg Heinicke wrote: On 02.06.2008 05:56, Sylvain Wallez wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? For being able to reset the response buffer for error handling. This is also possible with java.io.BufferedOutputStream, if the buffer size is big enough (current default value is 1MB), but then the buffer byte[] is always that big rather than increasing. That's what's happening right now, if you don't specify -1 as buffer size. -1 means complete buffering which on the other hand might lead to OutOfMemoryError [1]. In addition our BOS counts the bytes so that we can use the value to set the content length header. Got it. I'm using a similar technique with a servlet filter providing the response with a ByteArrayOutputStream that gives the size and has the convenient writeTo(OutputStream) method. Now in my case [1] pages are always small and I don't need to put a high limit on the size of the buffer. Sylvain [1] http://bluxte.net/blog/2008-04/29-54-29.html -- Sylvain Wallez - http://bluxte.net
Re: BufferedOutputStream
Joerg Heinicke wrote: On 29.05.2008 00:06, Joerg Heinicke wrote: Only issue I want to solve before the release is the BufferedOutputStream issue. I planned to do it this weekend. Done. Please review the file attached. It's still completely untested. At the moment I need some sleep ;) I will write junit tests for it this week and eventually commit it. Stupid question: why do we need a special BufferedOutputStream? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [OT] Mac OS X and Java development
Joerg Heinicke wrote: On 03.04.2008 23:33, Jörg Heinicke (JIRA) wrote: With Mac OS X I also have no access to the source code of the JDK. Which makes me wonder again how to do serious Java development with Mac OS X. I know a few of you guys are using Mac OS X. How do you do it? Er... without any problem, and I nothing would make me swith back to Windoze :-) Whenever I start this I get annoyed very fast. The missing Java sources are only the tip of the iceberg. What missing Java sources? They are in /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/src.jar Every tree representation in Eclipse just sucks. What sucks? The missing vertical lines? It means a bit more indentation, but less visual clutter. And my Mighty Mouse's scroll ball does magic to navigate in all directions :-) Keyboard navigation in Mac OS X is completely inconsistent, especially with Java programs. Uh? What is consistency besides the usual cut/copy/paste? Note that I don't use anything else than a Mac, so maybe I'm just used to the Mac's own consistency :-) There seems to be no serious SVN command line client (or at least the CollabNet download page is just self-linking at the moment: http://downloads.open.collab.net/binaries.html). Install macports and just run sudo port install subversion And so on ... Windows has also bunch of annoying issues but there is at least consistency and usually there is a solution for everything. Do you guys all switch to Linux when it comes to Java development? :) Nh. I'm very happy with my Mac :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? It would be great to have better docs, but honestly who is going to write them? We can either release with the docs we have or wait forever for better docs and never release. From these two choices I prefer the first one. Anything between these two extremes is imho not going to happen. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. If we wait for better docs we loose everyone as we never release. Yup. And add to this the fact that doc lifecycle is different from the software lifecycle, since there is no doc releases, but a continuous improvement. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Dev at weitling wrote: Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! I think we all agree that we need docs (or more/better docs), absolutely no doubt. And I think we also agree that writing docs is one task of the development process, and it's an important task. But we can't force anyone to write docs; and delaying a release because of lacking documentation is not producing the desired effect: instead of getting docs this way, nothing is usually happening: no docs and no release. I don't say that I'm happy about this. Yes. That's exactly what I meant! Thanks for making it clear Carsten :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Meeting in Amsterdam
Reinhard Poetz wrote: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) I'll arrive on tuesday evening and thus will miss the hackaton. But I'll be happy to discuss with those who were there about this interesting subject! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Exploring Corona
Carsten Ziegeler wrote: Intersting stuff - thanks Reinhard and Steven for starting this and sharing it with us. Finally I had time to have a *brief* look at it and I have some remarks :) I think the pipeline api and sitemap api should be separate things. So the invocation should rather be in the pipeline api as the base of executing pipelines. We could than split this into two modules. I'm not sure if actions belong to the pipeline api; i think they are rather sitemap specific. All they do wrt to the pipeline is to change the invocation perhaps. So this could also be done before starting the pipeline and get the action stuff out of the pipeline api. Yes, actions definitely don't belong to the pipeline API. They are sitemap control structures, just like matchers and selectors. The main difference between matcher and action (besides the pattern/src attribute) is that actions are allowed to have side effects while matchers should not. The classes should be put into different packages: we should separate between the pure api, helper classes and implementations. This makes it easier to use the stuff in an osgi environment. Ok, final comment for today, the idea of abstracting the consumer and the producer seems appealing. It's like the javax.xml stuff (Result, Source); the javax.xml stuff has the advantage that the implementation knows which results and sources are possible: there are only a handfull of subsclasses; adding own results or sources simply is not supported. I fear we will have to follow the same path (which might not be bad). Reminds me of some old thoughts I had about a Cocoon 3. This can be the role of a collection of adapters that would convert data for components that can't directly talk to each other. This complexifies the picture a bit, but would allow for advanced things such as non-XML pipelines, mixing SAX, DOM and StAX transparently to e.g. perform some content-aware construction of the pipeline, etc. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: JNet integration
Carsten Ziegeler wrote: It seems that this topic is even more interesting than the environment abstraction threads we had a while back :) Ok, first of all, the sourceresolver is a very cool component and I really like it (and it was also me who started this component years ago :) ). As the java api lacks such kind of an abstraction, its good to have it. Does it? It seems to me the URLConnection class provides the same level of abstraction and functionnality than a Source. Other approaches like the Spring resource stuff are not as good as they are not very flexible. So, it doesn't make sense to drop this stuff for Cocoon - seeing Cocoon as the big framework for building web applications. But on the other side we are talking about making Cocoon more modular and easier to understand. The Corona work is a great start and for me it makes totally sense to base the core api just on the java net stuff. It's much easier to understand and use. When we were doing Cocoon trainings, it was always a little bit difficult to get the point across that people should use the source resolver and not the file api or the java net api. Not a big deal, but still it adds more new stuff on top of the core api than you might need. While the source resolver, source factory and source interfaces are of great use, I'm not so sure about the extensions of the source interface like modifiable source or traversable source. I rarely needed them through the years, but your mileage might vary. Caching is very important and the java api does not provide a very good way to support caching in general. The source abstaction was built with caching in mind. Hmm... If this is just about Source.getSourceValidity which is optionally implemented (non-caching source can simply return null), we could equally well have a CachableURLConnection. If you look at the pipeline caching we have in cocoon it is rather complicated (it can cache partial pipelines etc.), and during the years we switched for a time based/event based caching of complete pipelines. But again your mileage may vary. The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. The main need for the Source abstraction was to circumvent the staticness of URLStreamHandlerFactory. Otherwise, pretty much everything we need is there: - extensible framework for cacheable, modifiable, traversable, whatever-able sources with URLConnection sub-classes, - integrated parsing/conversion features with the getContent() method - source-resolving using the URL(URL context, String spec) constructor The staticness problems of URLStreamHandlerFactory are still there in the JVM, but the OSGi/Equinox guys have found creative ways to circumvent them on most JVMs. If we're happy with this solution, it seems to me the Source abstraction is one of the many cocoon-isms we should consider to gently deprecate just as the copy of the servlets that we have in our environment abstraction. Fewer new concepts to learn for newcomers, fewer specific concepts that hinder the integration of Cocoon with other environments. My 0.02 euros (which are worth their $ these days!) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: JNet integration
Reinhard Poetz wrote: Reinhard Poetz wrote: What about the developer? He could assemble pipelines this way: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(baseUrl, xyz.xml); pipeline.addComponent(new XSLTTransformer(baseUrl, xyz.xslt); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); uuups, small correction: 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)); Or even using method chaining new NonCachingPipeline() .setBaseURL(new URL(file:///C:/temp/)) .setGenerator(new FileGenerator(xyz.xml)) .addTransformer(new XSLTransformer(xyz.xslt)) .setSerializer(new XMLSerializer(new StreamResult(System.out))) .process(); Sylvain -- Sylvain Wallez - http://bluxte.net
Re: SourceResolver in SSF
Carsten Ziegeler wrote: Grzegorz Kossakowski wrote: Thanks Carsten for a summary! To be honest, I'm not sure what kind of action we should take here. What you described sounds great and it's very tempting to have sources properly working with just standard URL class. Anyway, I'm little bit worried that whole things bases on *ugly* hack. I'm wondering how reliable the solution is. I have a few additional questions: 1. Has this technique (not necessarily JNet's implementation) been used in some project? Or it's your brilliant invention? :-) Hehe, no, afaik other projects are using this as well and I borrowed the idea from there and made my own implementation. Among the projects is Equinox, the platform for Eclipse. I think there are some other projects out there using this as well. Yes, IIRC this was born in Equinox when some people started using OSGi in webapps. Felix also has an implementation, which seems to take a large variety of JVMs in to account [1] It might be worth considering a common low-level layer to handle this in various contexts (Felix, Cocoon, etc) Sylvain [1] http://svn.apache.org/repos/asf/felix/trunk/framework/src/main/java/org/apache/felix/framework/URLHandlers.java -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: snip/ Thinking further, in my opinion it is a great chance to attract new developers and users because one of the main goals of Corona is that it can be easily used from within different environments. This would mean that it may become attractive to many other (opensource) projects (again). I hope you (and many others) give Corona a chance and take a look at it. Agreed. What about officially announcing our effort at main site with simple manifesto? I have a feeling that we agree on fundamental goals so writing such a document shouldn't be a problem, right? I don't think this is a good idea. The cocoon.apache.org website is for our users, and talks about stable or upcoming releases, even if 2.2 has been upcoming for years ;-) Corona is a different thing, because it is an experiment started by some members of the community, that other members are interested in looking at, and *may* become something we release in an unknown future, or simply be trashed if we decide it's an effort not worth pursuing. So it is way too early to talk about it to the people visiting cocoon.apache.org, especially as 2.2 is close to be released as final. Releasing 2.2 and announcing a revolution would give a very disturbing message. I would like to see as many as possible people participating or at least aware of the move. The move isn't decided yet. But you can count on the people on this list to jump in if they find it worth it. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Luca Morandini wrote:
Sylvain Wallez wrote:
So we can take a different approach, and consider that we can use
plain programming languages rather than grow our own
pseudo-languages. A well-defined Java API and its Javascript
binding would make people way more productive than an XML-based
language like the sitemap.
Do you mind terribly showing me an example of the use of this API ?
Something like:
CocooonStream stream= new CocoonStream(file, documents/mydoc.xml);
stream.transform(xslt, xsl/doc2html.xsl);
return stream.serialize(html);
Yes, something like that. But add in the mix the often discussed
content-aware selection (see [1] for the Flickr API):
CocoonStream stream = new CocoonStream(url,
http://api.flickr.com/services/rest/?method=flickr.test.echoname=foo;);
if (stream.inspect(xpath, /[EMAIL PROTECTED]'ok'])) {
doSomeUsefulApplicationStuff();
stream.transform(xslt, xsl/flickr-success.xsl);
} else {
stream.transform(xslt, xsl/flickr-error.xsl);
}
return stream.serialize(html);
I understand the usefulness of having a programmatic API and this
approach plays well with the Java monoculture, but, there aren't
libraries already doing that ?
I don't think we're talking about monoculture here, but about avoiding
the clumsyness of a reinventing a real programming language in XML. Such
an API can be mapped to the language of your choice: Javascript, Python,
Ruby, Scala or whatever language is available on the JVM, including but
not limited to the sitemap.
About existing APIs, javax.xml.transform addresses part of it (it
doesn't have stream inspection though) but it often perceived as
difficult to grasp from the simple fact that you have to wire the
pipeline backwards, starting with the serializer.
Sylvain
[1] http://www.flickr.com/services/api/request.rest.html
--
Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Luca Morandini wrote: Sylvain Wallez wrote: snip/ About existing APIs, javax.xml.transform addresses part of it (it doesn't have stream inspection though) but it often perceived as difficult to grasp from the simple fact that you have to wire the pipeline backwards, starting with the serializer. Ok, but... (bear with my my ignorance a bit more) is *that* difficult to develop such an API ? I mean, the classes dealing with the sitemap are already doing that, isn't just a matter of spreading an API over them ? Oh, I don't think it's a giant task, and what we wrote in this thread is pretty close to the current pipeline interface [1]. But it was designed as support code for the sitemap because this was the target goal, and thus it contains some sitemap-isms. We probably need to polish it by thinking the other way around, i.e. start aim at a clean Java API on top of which we can add and XML language... if we want. Sylvain [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-api/src/main/java/org/apache/cocoon/components/pipeline/ProcessingPipeline.java -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Steven Dolg wrote: Hi guys, I guess its about time to write something myself... As a colleague of Reinhard I participated in the Micro-Cocoon effort in February. Just as Reinhard wrote, at the end of those 3 days, there was the idea of doing a rewrite. Nice work, I'm eager to have a look at it :-) The number of use cases and the appr. 5500 lines of code indicated by Cobertura made this idea seem like an attainable goal. Nonetheless this is/will be a challenging task - and I am attracted to challenges. ;-) We believed that a working sitemap interpreter (without any components) could be created in about two days time. So I simply attempted to do so and so far things are developing as we envisioned. I wouldn't consider a sitemap interpreter as being a primary goal for Corona (or whatever its final name). This language was initially meant to be a simple and efficient way to define pipelines. Now over time features have been added and added again, because the complexity of what people had to do required it. And even with that, people have been very creative (even overly creative) in ways to distort or abuse the sitemap language because it was still too limited. So we can take a different approach, and consider that we can use plain programming languages rather than grow our own pseudo-languages. A well-defined Java API and its Javascript binding would make people way more productive than an XML-based language like the sitemap. My 0.02 euros Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote: Reinhard Poetz wrote: So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? If you don't mind, commit it to the whiteboard. I'm heavily interested in the stuff :) +1. I'll be coming back in the XML transformation world pretty soon, and was already thinking about a super-lightweight pipeline library... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: C2.2 dojotoolkit
Dev at weitling wrote: Hi Sylvain, thanks for answering. Sylvain Wallez wrote: Prototype/Scriptaculous has a smaller scope than Dojo that brings loads of features. You don't have to use all of them though and can strip down Dojo with the compressor they provides that embeds and obfuscates everything you need in one file. Prototype also considers that it owns the page and tweaks the prototype of many built-in classes such as Object, Array, Element, etc. This makes code more compact but has the very important drawback of breaking other libraries you would like to use in the same page (particularly the for (prop in object) construct no more works as expected). Yes, recently I've seen that, too, using Scriptaculous in a current PHP project. Seems rather invasive. As far as documentation is concerned, I have no opinion, digging in the code more often than reading the documentation :-P Thank god docs of Dojo have improved, the only book I could find is cheap but rather thin (Dojo Toolkit. schnell+kompakt by Michael Seemann). You german people have lots of german books ! Tech writers in France often write in english for US publishers... who sometimes also publish a french translation! That being said, upgrading to Dojo 1.x is definitely something to be done. I personally don't have the cycles for it though... And I lack the knowledge :-/ Where do you live? So I can start a pilgrimage to convince you ;-) http://maps.google.com/maps?f=qhl=engeocode=q=pechabou,+fr But as for every pilgrimage, you have to walk on your knees all the way :-P Sylvain -- Sylvain Wallez - http://bluxte.net
Re: C2.2 dojotoolkit
Andy Stevens wrote: On 05/02/2008, Sylvain Wallez [EMAIL PROTECTED] wrote: Dev at weitling wrote: Prototype/Scriptaculous has a smaller scope than Dojo that brings loads of features. You don't have to use all of them though and can strip down Dojo with the compressor they provides that embeds and obfuscates everything you need in one file. Prototype also considers that it owns the page and tweaks the prototype of many built-in classes such as Object, Array, Element, etc. This makes code more compact but has the very important drawback of breaking other libraries you would like to use in the same page (particularly the for (prop in object) construct no more works as expected). Just a random thought... If I understand it correctly, dojo is only used by the presentation aspects of the forms block, and only when ajax is enabled; if ajax is not enabled, the forms are processed differently and don't contain any dojo references, just plain (X)HTML. If so, would it be possible to add alternative presentation transformations that use prototype/scriptaculous (or jquery, or ext, or yui, or ...) instead? That way it could use whichever library any individual site developer is most comfortable with (or which is already used elsewhere in the site). I guess to avoid having to add support for every available toolkit into the forms block itself, this part of it should be separated out into individual block dependencies (forms-dojo, forms-yui, etc.) and specifying which one to use would just be down to which of them you had in your app's pom and/or bean configurations. Or is this all a crazy dream and totally impractical? It is theoretically possible since the server-side stuff is pretty much toolkit-agnostic. Now it seems maintaining one implementation is already a problem, so I imagine having 2 or 3 implementations won't really address this problem... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: C2.2 dojotoolkit
Dev at weitling wrote: Hi Jeroen, if the migration to Dojo 1.0 tends to become a big piece of work what about migrating to Prototype/Scriptaculous (or similar)? I'm not the Javascript guru but it would be nice to have a feature list (including quality of documentation) for re-evaluating the client-side-javascript-library. Who was the developer introducing Dojo in Cocoon? What does he/she think about it? This is me :-) Prototype/Scriptaculous has a smaller scope than Dojo that brings loads of features. You don't have to use all of them though and can strip down Dojo with the compressor they provides that embeds and obfuscates everything you need in one file. Prototype also considers that it owns the page and tweaks the prototype of many built-in classes such as Object, Array, Element, etc. This makes code more compact but has the very important drawback of breaking other libraries you would like to use in the same page (particularly the for (prop in object) construct no more works as expected). As far as documentation is concerned, I have no opinion, digging in the code more often than reading the documentation :-P That being said, upgrading to Dojo 1.x is definitely something to be done. I personally don't have the cycles for it though... Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [PROPOSAL] Micro-Cocoon
Jeroen Reijn wrote: Reinhard, sounds like a good thing. I guess not only Indoqa will get a benefit out of this. Put it in the whiteboard, so if needed and possible other people can help out and perhaps join the discussion? +1 ! Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Commented: (COCOON-2126) CForms-Ajax-Update sends span instead of td
[ https://issues.apache.org/jira/browse/COCOON-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554366 ] Sylvain Wallez commented on COCOON-2126: A bit of warning: widgets are not block-level components, and are allowed in places where HTML would forbid a div. For example, it is perfectly legal to include a fd:label in a b tag where a div is not allowed. So replacing the span with a div can actually do more harm than good as a general solution. So we must have a special behavior for replacements in a tr that inserts a td rather than a span. Handling this server-side in jx-macros.xml (or JXMacrosHelper) seems quite complicated since we can't grab what is sent to the cocoonConsumer by the JXTemplateGenerator. The easiest way is most probably to handle this special case in BUHandler.js, in the handlers.replace function: if oldElement is a td and firstChild is an empty span, then replace firstChild with an empty td *with the proper id attribute* (so that it can be replaced again later). CForms-Ajax-Update sends span instead of td --- Key: COCOON-2126 URL: https://issues.apache.org/jira/browse/COCOON-2126 Project: Cocoon Issue Type: Bug Components: Blocks: Ajax, Blocks: Forms Affects Versions: 2.1.10 Reporter: Florian Weitling Assignee: Grzegorz Kossakowski Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, showQuestion.bind.xml, showQuestion.def.xml, showQuestion.js, showQuestion.tmpl.xml, sitemap-excerpt.xmap In a table the cells' entries are delivered by a repeater. When hiding a cell programmatically via WidgetState.INVISIBLE the bu:update contains a span instead of a tr or another hint to hide away the cell. This results in weird optics 'cause span is not allowed as child of a tr. My current workaround: Using divs with table* styles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] RESTful web applications
Reinhard Poetz wrote: Sylvain Wallez wrote: Reinhard Poetz wrote: snip/ 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. Interesting! Can you elaborate on why you think Cocoon is great for RESTful applications? Is it because of its URL pattern matching features? That's one half of the story. The other one is XML pipelines and content aggregation on an XML level (XML plays in many RESTful architectures an important role, at least in ours) which make Cocoon still very appealing to me. Actually all three together are the virus that has infected me long time ago at the good old Cocoon 2.0alphaX days. - o - Recently I've been thinking more and more about some kind of Micro-Cocoon[*] that consists of o a slimmed-down sitemap language available in as an XML and as a Java dialect (no component declarations, no sub-sitemaps, no resources, merged match/select), I wrote a simple Java library about 2 years ago (time flies!) that mimics the major features of the sitemap: pattern matching and variable substitution calling plain old servlets rather than pipelines. Not more than a dozen of classes :-) o a controller implementation that is optimized for being used in RESTful scenarios (similar to Apples) and o a lean forms framework that borrows some ideas from Webforms 2.0 and follows the principles of REST. Daniel and I had some discussions about it in Rome and I've started with some experiments but don't have anything substantial so far. All the parts mentioned above should be useable in parallel with a traditional Cocoon 2.2 application. Thanks to the servlet-service framework this shouldn't be too hard to be achieved. If this sounds interesting to anybody, just let me know. It does sound interesting. Now I'm wondering if XML pipelines still fit in the web application landscape. They are perfect for publication purposes, but webapps nowadays have been completely infected by Ajax and/or components approaches. On one hand, component-oriented approaches like GWT or Wicket essentially hide the HTTP protocol in favor of application-level Java code, and on the other hand the use of pure Ajax libraries such as Dojo, YUI, Ext and the like leads the browser to become a REST client using plain XML or JSON responses. From a REST point of view, this dichotomy is interesting since component-oriented approaches ignore REST principle while Ajax libraries more or less require to design applications as a set of REST services, thus making them almost ready for machine clients. But in both cases, XML pipelines are not really needed anymore IMHO, except as you mention to aggregate remote sources. But it is then more a concern of the business-logic side of the application rather than that of the part handling client requests. WDYT? About the limitations of current browsers wrt to the full set of REST features (e.g. methods other than POST and GET), the book Restful Web Services [1] proposes a number of interesting workarounds such as using a request parameter (which can be a hidden form field) to override some headers or complement the request. We could imagine a simple request filter that interprets these workarounds to present the servlets with the real pure REST requests. Sylvain [1] http://www.oreilly.com/catalog/9780596529260/ -- Sylvain Wallez - http://bluxte.net
Re: [RT] RESTful web applications
Reinhard Poetz wrote: snip/ 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. Interesting! Can you elaborate on why you think Cocoon is great for RESTful applications? Is it because of its URL pattern matching features? Sylvain -- Sylvain Wallez - http://bluxte.net
Bad press...
FYI: http://danilogurovich.wordpress.com/2007/11/09/struts-vs-cocoon-why-cocoon-lost-the-battle/ Interestingly enough, although the title leads to thinking yeah, another comparison of apples and oranges since Cocoon and Struts don't have much in common, the comparison is actually not technical and the guy recognizes the strength of Cocoon. But it shows that the entry barrier to Cocoon is really too high. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Apache Cocoon 2.2-RC2 Released
Reinhard Poetz wrote: The Apache Cocoon Community is proud to announce the second release candidate of Cocoon 2.2. Good job folks! And let's hope that 2.2 final will be here for Christmas! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Cocoon, a survival tool
Grzegorz Kossakowski wrote: More seriously, Sylvain, are you going to attend CocoonGT this year? I would love to meet you there! No, unfortunately I won't make it. I would have loved to meet all of you young and old cocooners, but my (lack of) involvement hardly justifies the expense and various issues require me to be at work in early october. Sylvain -- Sylvain Wallez - http://bluxte.net
Cocoon, a survival tool
Cocoon is a place to find shelter in extreeme conditions and environments http://www.coroflot.com/public/individual_file.asp?individual_id=81605portfolio_id=218380sort_by=1; :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Carsten Ziegeler wrote:
Felix Knecht wrote:
Take a look at sitemap[1] in cocoon-forms-impl; there is following
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
map:match pattern=resource/external/forms/**.js
map:read src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter
map:parameter name=deprecated value=true/
/map:match
I think this is should not go into the reader. It is not the task of the
reader to inform you about deprecated sources (going down this path
would require to add this logic to generators etc. as well).
I think a separate component is the way to go - and yes, I think this is
an ideal case for the unfamous action component :)
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Nothing that can be done with an action though...
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Yeah, sounds good as well - this statement has the advantage that it's
always configured and it looks a little bit nicer.
Nothing that can be done with an action though...
^^^
Nice typo :)
Ooops, actions are so evil that they induce typos :-P
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo
Giacomo Pati wrote:
snip/
In Maven 2 you can actually do
repository
idprovided.local/id
nameLocally Provided Repository/name
urlfile:${project.basedir}/repository/url
...
/repository
to achieve the same
Ah cool. I tried something similar 1.5 year ago but never managed to
have it work. Glad to see it is possible.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo
Grzegorz Kossakowski wrote: Sylvain Wallez pisze: Grzegorz Kossakowski wrote: Is it impossible with Maven to use a local library? I must admit I have not thought about this option, I guess I'm too accustomed to the fact that everything is on Maven's repository. There is a bit of information here: http://maven.apache.org/guides/mini/guide-installing-3rd-party-jars.html and here: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html. However, such a solution helps only if one checkouts sample from svn and does mvn install. We can't release a pom that depend on something that we install manually to local repository. It's quite easy and quick solution but only temporary, IMHO. Sylvain, I know that you use Ivy, how it works there? Well, you can do pretty much what you want with Ivy, since it is basically used to build an Ant classpath from an ivy.xml file that describes the project's dependencies. The dependencies are resolved using a chain of repositories. In this particular case, we could have a chain consisting in a local repository (checked in in SVN), Cocoon's own repository and then the main Maven repository. And since this is really about building a classpath (the library path in this case), we don't actually _need_ a local repository, and can build a classpath that is the concatenation of artifacts pulled from a repository and jar files in a local-lib directory. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Module cocoon-forms-sample depends on JDBI that is not on Maven repo
Grzegorz Kossakowski wrote: Hi, I created the bridge that was discussed in thread[1] and first impression is that it will work. I have successfully run Avalon component with database connection defined that way: bean name=personnel class=org.springframework.jdbc.datasource.DriverManagerDataSource property name=driverClassName value=org.hsqldb.jdbcDriver/ property name=url value=jdbc:hsql://localhost:9002/cocoondb/ /bean so the result is quite encouraging. My solution is totally transparent for users and very unobtrusive for Cocoon itself. I tried to check it with Forms SQL samples also but I have not managed to run it because we depend on JDBI that is not on Maven repository. The question is: what's now? Should I contact with developer and ask him politely to upload his work to Maven repository? Is it impossible with Maven to use a local library? Sylvain -- Sylvain Wallez - http://bluxte.net
[jira] Assigned: (COCOON-1303) Small API change to access sitemap data structure
[ https://issues.apache.org/jira/browse/COCOON-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Wallez reassigned COCOON-1303: -- Assignee: (was: Sylvain Wallez) Small API change to access sitemap data structure - Key: COCOON-1303 URL: https://issues.apache.org/jira/browse/COCOON-1303 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.5 Environment: Operating System: other Platform: All Reporter: Sandor Spruit Priority: Minor I'd like a method that I can call to recursively walk through the sitemap data structure - probably some sort of finite state automaton stuff. At the Cocoon GetTogether, Sylvain suggested that this might actually be quite easy. I'd like to see whether I can visualize the sitemap of a running server, i.e. not just some small fraction of it, not process sitemap.xmap using XSLT. Perhaps try to visualize it using hyperbolic trees of some sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OT] pronunciation
Joerg Heinicke wrote: On 20.04.2007 15:48, Grzegorz Kossakowski wrote: Sorry, Grek, I didn't know this! Would be interesting to know how your name is pronounced? Does one simply skip the first z? It would be too simple to just skip z ;-) Actually rz is one consonant and should be read as whole. Pronouncing is tricky because rz occurs two times and is pronounced a little bit differently each time. Also when you want to skip the z you probably want to apply German pronunciation. I guess it's hard to tell for Grek if you can just skip the z ;) Actually I have a similar problem at the moment with the visa. Not so much with pronunciation, but with spelling. Non-Germans tend to simplify the ö (o umlaut) to a plain o, while it actually must be oe. If I don't get into the US at the end, you know why ;) I think, I'll need to provide a mp3 file some day because I really lack skills to explain it using plain, written English ;-) Looking forward to it! :) Grek, put it on your blog! I'm curious as well to hear how your name should really be pronounced! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Make status code attribute of seriailzers expandable
Reinhard Poetz wrote: I propose making the status code attribute of serializers expandable. This makes it easier to provide REST style services with Cocoon that make use of the different meanings of status codes. +1. Should have actually been there right from the start! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Daniel Fagerstrom wrote: Sylvain Wallez skrev: snip/ A very concrete example: within a Wicket application, we needed to have areas of the screen be the result of the transformation of some XML document. We ended up doing coding pipelines in plain Java. If Cocoon had provided a simple way to use its pipeline machinery, we would have used it. Although it could be even easier and most definitively should require less dependencies it is not that hard to use the pipeline standalone: http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java. For the dependencies we have done some work on splitting up Cocoon so that you can use just the pipeline part (see http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing left to do is to de-Avalonize a number of core components. Very cool! All this to say that by trying to address too many concerns, Cocoon dilutes the message of where its strengths are, and leads potential newcomers to simply look somewhere else. We clearly need to have a more focused message. But I think that saying that we should not provides a webapp framework anymore but just some components would be to go far to long. We need to find the right balance. A way to address this would be to have several subprojects in the Cocoon top-level project, ensuring a greater technical separation, giving a clear view of the various features the top-level project provides and thus allowing people to pick-up what they need, and ultimately use more and more of what this project provides. We are going in this direction. Both the cocoon-spring-configurator and the cocoon-servlet-service-fw (and maybe some more) are intended to be separate Cocoon sub projects. Lots of work left to do though. IMO this is key for the future of Cocoon: showing that it's not (or no more) a take-it-all-or-nothing beast, but a component statck where you can pick up only what you need. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Daniel Fagerstrom wrote: I don't propose that we should throw out the current Forms framework. What I do propose is that it could be improved so that it would require less work to use and so that it would support AJAX+REST style webapps better. Don't repeat yourself = As an alternative to using XML configurations for form definition and binding both the form definition object and the binding object could be configured from annotations in the model bean. With some decent set of conventions, people who follow the conventions would be able to connect forms to the business model with considerably less code writing. JBoss Seam is a good example of what I have in mind. AJAX+REST friendliness == IMHO the preferred webapp architecture will move from MVC model 2 towards the kind of architecture described in figure 2 in http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html and in http://websphere.sys-con.com/read/196269.htm. One way to support such a architectural style with our forms framework would be to refactor it so that it allows for a more RESTish communication style. Think about the form instance as a resource that can have JSON (or XML) representation that you can GET, PUT, POST or DELETE. One could also have support for letting the client ask for tthe data types of the form for supporting client side validation. I heartfully agree with these goals and it's true that CForms, more than old-fashioned, looks heavyweight compared to more recent solutions that considered partial page update and/or RPC-style interaction right from the beginning. Now the question that comes to mind when considering these goals is: Is this still Cocoon? So what is Cocoon: - an XML processing engine? - a REST platform (sitemap matchers)? - a webapp framework (flowscript, CForms)? - a block container for Spring components? - an OSGi bridge/integration platform for blocks? The still unique distinguishing features of Cocoon are the two first ones. When we progress in the stack, more competition and more modern solutions appear. Also, XML processing is powerful for data aggregation, filtering and transformation, but quickly shows its limits for business logic (nah, XSP+SQLTransformer is not a nice solution). For RPC-style webapps, you definitely don't need Cocoon, because there's no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected to plain Java code. For component-based webapps with partial page updates, Wicket [2] is really productive. All this actually reminds me of some old prophecy [3]. Rather than coming with its own solution for each and every aspect of server-side app development, the future of Cocoon is IMHO paradoxically in its past: XML processing engine and REST platform. By providing a very simple way to integrate these features in any context, it will allow people that use other more modern/mainstream approaches to use Cocoon. A very concrete example: within a Wicket application, we needed to have areas of the screen be the result of the transformation of some XML document. We ended up doing coding pipelines in plain Java. If Cocoon had provided a simple way to use its pipeline machinery, we would have used it. All this to say that by trying to address too many concerns, Cocoon dilutes the message of where its strengths are, and leads potential newcomers to simply look somewhere else. A way to address this would be to have several subprojects in the Cocoon top-level project, ensuring a greater technical separation, giving a clear view of the various features the top-level project provides and thus allowing people to pick-up what they need, and ultimately use more and more of what this project provides. And also providing bridges to the other mainstream solutions rather than trying to embrace them, thus giving mindshare to Cocoon in other communities. Sylvain [1] http://getahead.org/dwr [2] http://incubator.apache.org/wicket/ [3] http://thread.gmane.org/gmane.text.xml.cocoon.devel/55131 -- Sylvain Wallez - http://bluxte.net
Re: [RT] Modernizing CForms
Grzegorz Kossakowski wrote: Daniel Fagerstrom napisał(a): I don't propose that we should throw out the current Forms framework. What I do propose is that it could be improved so that it would require less work to use and so that it would support AJAX+REST style webapps better. Don't repeat yourself = As an alternative to using XML configurations for form definition and binding both the form definition object and the binding object could be configured from annotations in the model bean. With some decent set of conventions, people who follow the conventions would be able to connect forms to the business model with considerably less code writing. JBoss Seam is a good example of what I have in mind. I tend to agree with this one. I'm also supporter of less configuration-demanding solutions and conventions where applicable. I fear only if Java world (and we in particular) eventually leap from the XML hell to the annotations hell. I can imagine this situation and would like to avoid it. AJAX+REST friendliness == IMHO the preferred webapp architecture will move from MVC model 2 towards the kind of architecture described in figure 2 in http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html and in http://websphere.sys-con.com/read/196269.htm. One way to support such a architectural style with our forms framework would be to refactor it so that it allows for a more RESTish communication style. Think about the form instance as a resource that can have JSON (or XML) representation that you can GET, PUT, POST or DELETE. One could also have support for letting the client ask for tthe data types of the form for supporting client side validation. I wonder where are the limits. Is it valid to treat browser as VM machine where we execute complicated (name them Rich) client applications? Although such an idea is nice, when I think of IE all the simplicity and flexibility of the solution seems to flow away to some nowhere land. Am I only one not so enthusiastic about AJAX everywhere vision? The IE gives me shudders feeling is partly one of the reasons for Ajax toolkits to exist. This unfortunately doesn't solve everything, but helps a lot! Maybe I'm just ignorant but... is there any multi threading capability on browser side? Is it only me experiencing Firefox freezing while dojo toolkit is being loaded? No, JavaScript is not multi-threaded, and although there are discussions IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it on our browsers for many years. The freezing you experience is that because you're using an uncompressed Dojo, and every dojo.require() potentially does a _synchronous_ XmlHttpRequest, hence freezing the browser. The solution, that has to be used for any production deployment, is to use Dojo's compressor to group all JS files used by an application into a single compressed one. No more freezing in that case. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [GT2007] It's that time of the year again...
Gianugo Rabellino wrote: On 3/16/07, Reinhard Poetz [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Arje Cahn skrev: Hi all, (quoting Joerg quoting the Cocoon analysis report that Daniel found:) Over the last twelve months, Cocoon (Apache) has seen a substantial increase in activity... Good news! What about a Cocoon GetTogether 2007? +1! stuff-I-might-regret-soon *cough* Italy? *cough* :-) /stuff-I-might-regret-soon Yeah! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: cocoon.processPipelineTo()
Leszek Gawron wrote: Mark Lundquist wrote: Hi, I seem to remember from a long time ago, some mention of something that could be used in place of processPipelineTo(). Something that might have been better, or... not sure. Anyway, does this ring any bells? I can't seem to find the reference now... best regards, —ml— PipelineUtil? Yep. Provides an easier way to call pipelines from flowscript to stream, sax, dom, etc. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. +1 Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [graphics] Artwork for cocoon.apache.org - new version
hepabolu wrote: Guys, after some discussion back and forth with Thien we've decided on the next version: snip/ Getting nicer and nicer! I think you can remove the french flag on the right: the french pages we have on the website only translate the main what is Cocoon blurb and introduce the french-speaking mailing list. Unless somebody feels the itch to maintain this, I think just adding users-fr@ subscribe/archives information on the mailing-list page would be good enough. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [graphics] New version of masthead
Niclas Hedhman wrote: On Tuesday 06 February 2007 00:22, Peter Hunsberger wrote: Very nice. I'm with the camp that would like to see it shrink a little, not much but just a little. Also, I still find it a little on the pastel side, I'd like to see a version with bolder colors. And I realize that asking developers for opinion on style and good taste is like asking sheep farmers to comment on Versace's latest designs; They are in the supply chain, but hardly the target audience... ;o) Mo :-) Perhaps widening the audience to the user's lists is a good move. Collecting opinions is good, but we also need to define the decision process to avoid endless discussions and frustration in the end for those that may have the feeling the decision was imposed on them. Having Thien and Helma making the final choice is fine if everybody knows it in advance. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [graphics] New version of masthead
hepabolu wrote: Guys, Thien did it again. He created a great new version of the blocks masthead and redesigned the rest of the homepage. http://people.apache.org/~hepabolu/final.html I don't want to bias you, but I like it a lot. ;-) WDYT? Wow! Very nice! Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Not caching pages with continuations (was:...where is 304?)
Ard Schrijvers wrote: Hello, Ard Schrijvers wrote: snip/ This is actually almost the same hack we used, but instead of a transformer a selector, and if some value set in flowscript, an action to set headers. Because we are outsourcing/other parties using our best practices, and I did not want them to have to think about setting things in flowscript like sessions and values to indicate caching headers, I chose to put it in the black box transformer, which handles it. Of course, also kind of a hack, because users aren't really aware of it (certainly because i did not want another sax transformer, so I did add it to the StripNameSpaceTransformer which is by default used by us in front of the serializer. But it does more then its name suggests, and therefor, it is hacky ofcourse. But...at least nobody has to think about it :-) ). I wondered if there was a solid nonhacky solution to the issue If it's for CForms, we can add the setting of no-cache headers in Form.js since it's very unlikely that a form pipeline will be cacheable. Think we tried similar things (in flowscript), but we found the problem Bertrand also faced about the fact, that you have to set the headers on the pipeline the serializer is used from (but all requests for example arrive at a catch all matcher, which does not know wether it includes a form or not). Do you think you can set it globally for the request in Form.js? I tried directly manipulating the HttpServletResponse, but obviously, this resulted in correct behavior on the first request, but consecutive cached responses did not have this direct HttpServletResponse manipulation, so this implied uncacheable pipelines in cocoon, which of course, I did not want either. Cached responses don't involve the serializer, and this is why the headers aren't set. On the contrary, the flowscript is always executed, meaning headers will always correctly been set even if the pipeline it calls is cacheable (BTW why is this pipeline cacheable at all???) Also, response.setHeader() is ignored for internal requests. Si if the flowscript is called through a cocoon:, headers really have to be set on the Http request, accessible in the object model with the HttpEnvironment.HTTP_RESPONSE_OBJECT key. Sylvain -- Sylvain Wallez - http://bluxte.net
