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
