Thank you Francesco for your reply. That clarified my Cocoon upgrade path plan for the future. I will be looking forward to seeing C3 beta released :)
I must say that you guys are doing a really great job with Cocoon. I didnt find any other lightweight XML/RESTful engine that is so flexible and easy to develop on. jBoss 7 Community Edition is also in our consideration as an OSGi-based very lightweight/modular Web Services engine and has really small footprint but it still cannot beat C3 in terms of declarative way of handling XML chain processing. We tried also Apache Camel / CXF as another possible candidate to meet our goals, but it lacks some features. C3 looks like the best one. We live in times when there is a tremendous pressure to deliver short-term results/fixes and the price of introducing a new change must be very low. In my opinion C3 fits that like anything else. Thank you and please carry on with developing that wonderful piece of software. I hope to see OSGi support soon :) Greetings, Greg 2012/4/4 Francesco Chicchiriccò <ilgro...@apache.org> > Hi Greg, > sorry for the delay: you will find my reply embedded below. > > Regards. > > > On 02/04/2012 11:00, gelo1234 wrote: > > Hello, > > We've been using Cocoon framework for years and are very happy with its > simplicity and RAD features. > Although we use very old version of Cocoon (2.0.5), it still satisfies us. > Unfortunately there are some bugs inside those old framework libs that we > cannot fix as well as some memory leaks > from libraries that are no longer in use. That's why we soon plan to > upgrade to the newest release of Cocoon. > And i have few questions related to that topic: > > 1. Is C3 stable enough to give it a try in a production ? > > > Stable enough to give a try? Yes. > Ready for production? No, unless you have enough skills to dive inside the > source code. There are C3-based projects in production out there, but > latest release is alpha [1], and development version is still beta1. > > > 2. Is there any equivalent of XSP in C3 ? > > > Not really. As you say below, XSP were already deprecated in C2.1. > The only template mechanism available in C3 is StringTemplate [2] which is > way less flexible (and error-prone) than XSP. > > > The flexibility of XSP is very important to us in terms of introducing > many new/short changes > very fast to our web application. We just make a change and that's all - > cocoon engine recompiles the java-related > class and it is instantly available to us - no recompiling from our dev > team, no deployment, no app server restart no fuss at all! > It allows us for very rapid changes! That's exactly the kind of > flexibility we want to have in our dev environment. > And we were much worried when in next Cocoon releases the support for XSP > was abandoned. As far as i know > XSP became deprecated in C2.1.11 to be totally removed in C2.2.x and i > suppose in C3. > I didn't dig much into all the features of new Cocoon but it seems like in > C2.1/2.2 the best thing to use on the "controller" side > is Flowscript code. We were hesitating to switch from pure Java controller > code to Javascript/Flowscript > code because in my opinion the continuation mechanism is error-prone, yet > the developer must take care of many intricacies > around session/continuation expire times and so on. But the main reason > for us not to go for it was the language - > Javascript - NOT Java. Although if i get it right, you can just > instantiate any Java object and get access to any Java library available > around from Javascript, it is not as much flexible as java was in XSP. > Though it still doesn't require any recompiling!/redeployment phase > from the dev team as i assume. > In C3 you can have Java controllers called and that is Good, but it does > require recompiling the Java > class and redeploy it on the server (and restart app server?). So it will > be much much SLOWER than just dynamic-recompiling by cocoon engine without > any server restart. > So i wonder if there is any mechanism on the controller side available in > C3 that enabled us to still use Java but doesn't require from us > recompiling java code/making redeployment/restarting the application server > ? > > > Sure: you can empower cocoon-maven-plugin [3] for this, or even setup > something external like JRebel. > > > 3. Is Flowscript using some separate javascript engine like V8 ? Is it run > inside JVM as a dynamic language feature ? > Whats is a preferred method to be used as a logic controller in C3 - > Flowscript or Java ? > > > There is no support at all for Flowscript / continuations in C3. > > > 4. We don't want to go yet with C3 alpha-3 because it still uses old > Xerces and XML-API libs. We found out there are some issues with those old > libs under Tomcat 7 while working with "bloated" XML namespaces or handling > some SAX errors. They had led to some memory leaks in our environment. > I spotted on the changelog that you have just updated C3 beta to the > newest Xerces/XML-APIs. Thank you very much for this. I really appreciate > that important change. Can we have some light on when the beta is released? > > > Nice question, indeed :-) > I'd suggest to send a separate e-mail about this topic to dev ML. > > Regards. > > [1] http://cocoon.apache.org/3.0/alpha-warning.html > [2] http://www.stringtemplate.org/ > [3] > http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/1295_1_1.html > > -- > Francesco Chicchiriccò > > Apache Cocoon PMC and Apache Syncope PPMC > Memberhttp://people.apache.org/~ilgrosso/ > >
