Conversation scope/context for Cocoon Forms?
I've been using Cocoon Forms for years, and for the most part have really appreciated the functionality they have given me. There is one issue with them that has driven me to distraction and caused me more bugs and lost time than I care to remember: the lack of a way to create a conversation scope for injected objects that reflect the scope of the javascript continuations within Cocoon Flow scripts. This was earliest seen with Hibernate Sessions. Best practices were to use OpenSessionInViewFilter, which gave the hibernate session a request scope. But since you typically pull objects out of the database with one HTTP request to display on a web form, and then come back from a continuation with an edited version of that object in a new HTTP request, you end up with a new Hibernate Session but an object from your database from the old one. This leads to unbelievable drama trying to get the old object into the new session without stepping on another version that may have loaded as well, as well as having to do your own code to ensure nothing makes the old version out-of-date with regard to the database version. All the modern dependency injection frameworks have a way around this now. Spring uses Flow and Conversation Scopes[1]. Seam uses Conversation Context[2]. CDI (as shown by the Weld reference implementation) has a Conversation Context as well[3]. Guice has no specific conversation scope, but allows you to define your own custom one[4]. My question is whether there has been any work done by anyone to add this to Cocoon? As I see it, it would need to deal with these circumstances: 1) On entry to flowscript from the sitemap, inject any dependency marked as conversation scoped such as a JPA entity manager and run any initialization on it. 2) On saving a continuation, the dependency injected object must also be saved. There may be an interface function to do things like temporarily close open sockets, and if so there would need to be another method to reopen when a continuation resumes. 3) On exit of the top level flowscript function (assuming other flowscript functions may have been called from that), run cleanup on the dependent object and get rid of references to it. 4) On timeout of the continuation, run cleanup on the dependent object and get rid of references to it. Has anyone already done anything like this? I am still using Cocoon 2.1.11 but this concept is so critical to me I'd bite the bullet and do the work of porting to 2.2 if that was the way to get it. Thanks for any response on this. [1] http://blog.springsource.com/2007/05/08/spring-web-flow-bean-scopes-and-jsf/ [2] http://docs.jboss.org/seam/2.2.0.GA/reference/en-US/html/concepts.html#d0e3620 [3] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/scopescontexts.html#d0e1839 [4] http://code.google.com/docreader/#p=google-guices=google-guicet=CustomScopes
Cocoon Consultant needed for 2 to 4 week term
Hi. My company has a product that we developed using Cocoon as the Web Framework. We are facing challenges getting the application to scale to the point that we would like for the number of concurrent web users. We are looking for a Cocoon consultant who knows a lot about how to get better performance out of Cocoon, either by reconfiguring Cocoon or telling us how to change the way we use it. An added bonus would be someone who could help us begin the migration from Cocoon 2.1.* to Cocoon 2.2. You can email me at [EMAIL PROTECTED] if you are interested. If you know someone else that would be interested, please pass this message along to them.
Re: Avoiding OutOfMemory Errors by limiting data in pipeline
My only comment is that I think it would be good to allow the initial buffer size to be configurable. If you know the bulk of your responses are greater than 32K, then performing the ramp-up from 8K every time would be a waste of resources. For another web site, if most responses were smaller than 6K then an 8K buffer would be perfect. Allowing someone to tweak that based on their situation seems useful to me. Not critical though, if it is hard to do. Allowing the buffer to scale is the important thing. Joerg Heinicke wrote: On 27.04.2008 23:43, Joerg Heinicke wrote: 2. Does the full amount of the buffer automatically get allocated for each request, or does it grow gradually based on the xml stream size? I have a lot of steps in the pipeline, so I am worried about the impact of creating too many buffers even if they are relatively small. A 1 Meg buffer might be too much if it is created for every element of every pipeline for every request. That's a very good question - with a negative answer: A buffer of that particular size is created initially. That's why I want to bring this issue up on dev again: With my changes for COCOON-2168 [1] it's now not only a problem for applications with over-sized downloads but potentially for everyone relying on Cocoon's default configuration. One idea would be to change our BufferedOutputStream implementation to take 2 parameters: one for the initial buffer size and one for the flush size. The flush treshold would be the configurable outputBufferSize, the initial buffer size does not need to be configurable I think. What do other think? No interest or no objections? :) Joerg
Re: Layered software designs
I'm with you, too. Just as an example, I think it might be useful to use Corona as the basis for a new Ant task called Pipeline. That task could do any number text transformations to a set of files as part of a build process. Here, caching is a non-issue for the most part since the point of using a pipeline would be to process each file only once. Rather than either java.net.URL or SourceResolve, we'd probably want to feed the pipeline based on Ant resources[1], just as the existing XSLT task is fed. It may be that SourceResolver and an AntResourceSource is the best way to solve the problem, but on a cursory glance it sure looks like it is difficult to separate the banana from the gorilla[2] that is Avalon. [1] http://ant.apache.org/manual/CoreTypes/resources.html [2] http://www.ddj.com/architect/184408251 Torsten Curdt wrote: On Mar 26, 2008, at 14:44, Ralph Goers wrote: Reinhard Poetz wrote: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Just lurking but I am with you guys. Appealing? yes. Actually implementable in Java so that it isn;t even more complicated than what we have? I don't know. IMO this would simplify a lot as it separates concerns and the inner guts can be used in other projects without the pain of dependencies we have right now. People have been asking for this for years. I really think think this is the right direction. cheers -- Torsten
Re: Micro-Cocoon ... Corona
Carsten Ziegeler wrote: Reinhard Poetz wrote: This rewrite that we gave the name Corona consists of . a pipeline API (that isn't limited to XML pipelines but would also support connecting of any types of pipes) Do you have use cases for this? (Just curious) I can think of a lot of them. Any time you want to make replacements in text where the source is not XML this could be useful. How about replacing property keys with property values, just as an obvious example. Or translating a text file to another language by looking up phrases in a resource bundle. Sure, you could use a templating engine, but that may be overkill for some applications and besides, suppose you wanted to do several unrelated replacements that used different kinds of templates? Or suppose you wanted to make changes to HTML generated by some other website that doesn't generate XHTML or even very sensible HTML? There are many reasons you might want to do this: to extract a bit of content from the page, to filter certain words, to alter URLs. I wrote a spider once that archived the state of a web application as of a certain day. It crawled web pages and replaced URLs with file: URLs that pointed to where the web page was stored locally. This was complicated by the fact that many web pages with the same URL would display different data depending on request parameters, and so had to be stored in different places but still be pointed to by the links if you followed a particular path through the stored HTML files. This was only one of many cleanups I needed to make to the archived HTML. Cocoon didn't help me because there was no reasonable way to get the HTML into XHTML. A non-XML pipeline would have helped a lot.
RIA technologies - which technology will win
Unfortunately, that is not true of all environments. Many large organizations such as governments and big corporations will not allow their users to install ANY plugins to their browsers for security reasons. A team of testers has to examine every piece of software installed on the network and approve it. Getting variances for a particular application is beyond most people's level of bureaucratic tolerance. And since providing their employees access to sites like Youtube is pretty low on these organizations' radar, a Flash player is not something that it is easy to get passed as an accepted piece of software unless they have purchased other software that requires it. And THAT is unlikely because developing software for large organizations that requires Flash causes this major friction point for sales. For Flash, it is a vicious circle. Given how much development is paid for by large organizations, I think it unlikely any RIA technology will become dominant unless it is embedded in something else. That means SilverLight embedded in the browser with the most market share; JavaFX embedded in the JRE since many of these organizations see Java as mission critical; or Ajax, support for which is already embedded into existing browsers. Of these, Ajax is the only technology that is currently generally available within these large organizations. Just thought I'd offer another perspective. Grzegorz Kossakowski wrote: I'm taking installation issues into consideration but if your application is worth downloading and installing some VM people will do it. As long as it's matter of one-click installation people will do it even if they will have to go for a five minutes break caused by download size.
Re: [graphics] Artwork for cocoon.apache.org - final4
I think the suggestions that have been made to date have all resulted in a page that looks better, and good on you all for contributing them. But at this stage, it feels like you are arguing over the color of the bikeshed[1]. After all these rounds of feedback and integration, wouldn't it be better to just go with what you have? You'll never be able to please everyone, so trying for complete consensus is doomed to failure. If people decide the design needs tweaking later, then that can be done. But it seems to me that getting it out there as soon as possible (subject to Thien's availability) is more important than getting it perfect on the first try. Just thought I'd offer an outside perspective. 1. http://en.wikipedia.org/wiki/Color_of_the_bikeshed
