gmane.text.xml.cocoon.devel

[jira] Subscription: COCOON-open-with-patch

2008-12-03T18:41:44

Issue Subscription Filter: COCOON-open-with-patch (106 issues) Subscriber: cocoon Key Summary COCOON-2233 Update archetypes to current trunk artifact versions https://issues.apache.org/jira/browse/COCOON-2233 COCOON-2222 Add SaxParser configuration properties https://issues.apache.org/jira/browse/COCOON-2222 COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when

Re: [cocoon3] Stax Pipelines

Sylvain Wallez — 2008-12-03T11:35:28

Axiom is very interesting as the DOM-like structure it provides is the easiest way to traverse a document while avoiding full parsing of the document. But this comes with a price, since any traversal on a list of elements requires to parse all of these elements. So without very careful use, it can quickly degenerate into a classical DOM with the assiociated problems, or even worse because of the additional complexity required by deferred parsing. Not to say that Axiom is bad, rather the contrary: it's a powerful weapon which you can easily shoot yourself in the foot with :-) Should I say me too? ;-) I'm eager to see what it looks like! Same here! But don't forget in the torture program the important XSLT transformer, since I don't know of any implementation that would support pull callbacks and thus avoid buffering the ouput in a Stax pipeline. Sylvain

Re: [cocoon3] Stax Pipelines

Steven Dolg — 2008-12-03T09:56:35

Thorsten Scherler schrieb: We started with an evaluation of some StAX implementations including Axiom, WoodStox and the reference implementation. However quite early we felt that the DOM-like approach of Axiom is not ideally suited for our current phase. I'm quite sure that there are occasions where Axiom can be really charming, but I believe there are too many premises required to efficiently use it (e.g. you will want to be sure that the XML data is not too large). But if you have some complex transformation that appear to difficult to be implemented in a one-pass approach Axiom could probably do the trick. I'm sure we will explore this idea at a later time, though... I must admit that it got me all excited by now, too. Yesterday, I did a very minimalistic POC, just to make sure our current approach is not missing any major point. I have to say I was simply amazed how easy state handling can be when using StAX compared to SAX and I'm very confident that we came up with a pretty thorough concept

Re: [cocoon3] Stax Pipelines

Thorsten Scherler — 2008-12-03T08:31:22

El mié, 03-12-2008 a las 08:56 +0100, Sylvain Wallez escribió: ... I lately played around (and still do) with such approach in the forrest dispatcher rewrite [3]. I am using Axiom which is a quite interesting approach and maybe worth looking into [4]. However I did some profiling and for the dispatcher the old SAX approach had been ways faster. However this is due to the buffering issue pointed out by Sylvain which [5] is not solving at all. Brings me back to do a sax (+stax) approach again (the other class in the package). I am really exited about this thread. :) salu2 ... [3] https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher [4] http://ws.apache.org/commons/axiom/OMTutorial.html [5] https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java

Re: [cocoon3] Stax Pipelines

Sylvain Wallez — 2008-12-03T07:56:45

Hi Andreas and colleagues! Doh, sorry for that. But at least this brought some material for the discussion :-P Good to hear! I thought about that approach as well, but it doesn't avoid state management, which is the main complexity that Stax is supposed to solve. This is still a callback-based processing, although we have here pull callbacks rather than push callbacks. Now you're right: a single pull callback can consume several input events that are related, making it thus easy to process a subtree of several closely related elements from the input. It would for exemple radically simplify the implementation of the I18nTransformer where and have a nested structure. But in many situations the elements of interest to a transformer enclose large document sections that are to be propagated without modification. Examples are JXTemplateTransformer or FormsTransformer (but does anybody still use these instead of their generator replacements?), RoleFilterTransfomer

Re: [cocoon3] Stax Pipelines

Andreas Pieber — 2008-12-02T19:18:07

First of all, my name is Andreas and I'm one of the students working on the StAX implementation for cocoon. Therfore hello from my colleagues and me. Secondly me first post ever to the mailing list of an open source project and such a long post to answer. Thank you Sylvain ;) Nevertheless I'm going to try my best. We (if i say we, I mean us students strongly influenced by Reinhard and Steven :)) also thought about the problems described by you and came to the same conclusion. Therefore we're trying another approach. Pulling StAX-XmlEvents through the entire pipeline from the end. In other words, if we have a simple pipe of the following form: Producer - Transformer - Serializer the Serializer would have in its start method some code like: while(parent.hasNext()){ xmlOutputWriter.add(parent.getNext()); } retrieving the next event on the Transformer in this case and writing it into an XmlOutputWriter. The transformer on his self calls the getNext method on the Starter (in this case) which retr

Re: [cocoon3] Stax Pipelines

Sylvain Wallez — 2008-12-02T16:16:25

I have spent some cycles on this subject and came to the surprising conclusion that writing Stax _pipelines_ is actually rather complex. A Stax transformer pulls events from the previous component in the pipeline, which removes the need for the complex state machinery often needed for SAX (push) transformers by transforming it in a simple function call stack and local variables. This is the main interest of Stax vs SAX. But how does a transformer expose its result to the next component in the chain so that this next component can also pull events in the Stax style? When it produces an event, a Stax transformer should put this event somewhere so that it can be pulled and processed by the next component. But pulling also means the transformer does not suspend its execution since it continues pulling events from the previous component. This is actually reflected in the Stax API which provides a pull-based XMLStreamReader, but only a very SAX-like XMLStreamWriter. So a Stax transformer is actual

Re: [cocoon3] Stax Pipelines

Grzegorz Kossakowski — 2008-12-02T13:17:13

Reinhard Pötz pisze: Wow, what a surprise, Reinhard! I won't comment on actual proposal until I hear some details from the research that students have made but I would like to say "Thank you" to all people involved into this effort. It's nice to hear that there will be more students involved in Cocoon!

[cocoon3] Stax Pipelines

Reinhard Pötz — 2008-12-02T11:54:48

I've had Stax pipelines on my radar for a rather long time because I think that Stax can simplify the writing of transformers a lot. I proposed this idea to Alexander Schatten, an assistant professor at the Vienna University of Technology and he then proposed it to his students. A group of four students accepted to work on this as part of their studies. Steven and I are coaching this group from October to January and the goal is to support Stax pipeline components in Cocoon 3. So far the students learned more about Cocoon 3, Sax, Stax and did some performance comparisons. This week we've entered the phase where the students have to work on the actual Stax pipeline implementation. I asked the students to introduce themselves and also to present the current ideas of how to implement Stax pipelines. So Andreas, Killian, Michael and Jakob, the floor is yours!

Re: Where is Cocoon 3 going to?

David Crossley — 2008-12-02T01:55:04

I too was concerned when i saw new patches to re-implement something that Cocoon has already spent years developing. A little bit of discussion is a good thing. It enables the rest of the community to feel that they are still in touch with the direction of the project. -David

Re: Where is Cocoon 3 going to?

David Crossley — 2008-12-02T01:39:01

Thanks for your comments. Very important. It would be better if we all heard those explanations here on the dev list. Please encourage your collaborators to join us. -David

Re: [vote] Release Cocoon 3.0.0-alpha-1

Grzegorz Kossakowski — 2008-12-01T20:59:28

David Legg pisze: I wish it had been a party. ;-) Some of us are doing freaky-crazy probability theory these days! Anyway, it would be good if more people could find some time and test this work even briefly. It's has an alpha status and lots of warnings so it does not have to be perfect.

Re: [vote] Release Cocoon 3.0.0-alpha-1

Grzegorz Kossakowski — 2008-12-01T20:54:14

Reinhard Pötz pisze: Tested already Maven artifacts, and now distribution artifacts. Everything looks fine, here is mine: +1

[C3] What's the purpose of StatusCodeCollector?

Grzegorz Kossakowski — 2008-12-01T17:54:10

Hello, The subject says all. I would like to know something about this class and convert this knowledge into some documentation. Introduction of ThreadLocal always deserves at least a few bits of explanation.

Re: [vote] Release Cocoon 3.0.0-alpha-1

Peter Hunsberger — 2008-12-01T15:53:17

Sorta bad timing for those of us in the US: I haven't had a chance to even glance at the artifacts and I won't until I get caught up from Thanksgiving.. On Mon, Dec 1, 2008 at 9:35 AM, David Legg searchevent.co.uk>wrote:

Re: [vote] Release Cocoon 3.0.0-alpha-1

David Legg — 2008-12-01T15:35:17

Has everyone gone to a party that I don't know about?... or maybe we're all waiting for someone else to vote first ;-) Regards, David Legg Reinhard Pötz wrote:

[cocoon3] Creating idea configuration

Reinhard Pötz — 2008-11-29T17:26:56

I set the version of the maven-idea-plugin to 2.2 in the root POM. I hope that this solves your problem.

[cocoon3] Added a root POM

Reinhard Pötz — 2008-11-29T17:00:49

I added a minimal root POM but left as many settings as possible in the parent POM. HTH

Re: Where is Cocoon 3 going to?

Simone Tripodi — 2008-11-28T15:50:52

Hi everybody, I'm the younger person - in therms of cocoon's experience - who recently joined Reinhard and Steven in their enthusiasm about Cocoon3. Please let me spend my 0.2€ too, feel free moving this email in the spam or trash box :) Just a prelude: I've never experienced using oldest Cocoon's release, but months ago, while I was working on an important OpenID provider (for the biggest Italian Telecommunication company), I had the need to generate , manipulate, validate, transform and serialize large XML data set in various format. So I felt the need to use a solid framework able to help me in a quick and clear way... so, the miracle happened when I found "accidentally" the Reinhard's blog. My first word was just a "wow!", so I wrote an email to him. I was totally charmed, not only about Cocoon, but above all the collaborative way that both Reinhard and Steven demonstrated in explaining me how the new Cocoon works, helping me in adopting it in the way to resolve my problems and involving me in the de

Re: [vote] Release Cocoon 3.0.0-alpha-1

Reinhard Pötz — 2008-11-28T09:59:21

[vote] Release Cocoon 3.0.0-alpha-1

Reinhard Pötz — 2008-11-28T09:53:38

I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-1. You can find the staged files for all modules (sources, binaries, javadocs, checksums, gpg signatures) at http://people.apache.org/builds/cocoon/ SVN tags of all these artifacts can be found at http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/ The general distribution artifacts (tar, zip) can be found at http://people.apache.org/~reinhard/cocoon-staging/ I want to stress again that this is an alpha release. This means that we are free to change contracts without following any deprecation rules. This majority vote stays open for _at least_ 72 hours.