cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gelo1234 <gelo1...@gmail.com>
Subject Re: C3 and XSP equivalent
Date Wed, 04 Apr 2012 10:39:45 GMT
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ò <ilgrosso@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/
>
>

Mime
View raw message