cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha-Matthias Kulawik <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sun, 08 Jan 2006 23:45:26 GMT
Carsten Ziegeler <cziegeler <at>> writes:

> Sylvain Wallez wrote:
> > Tell me your thoughts. Am I completely off-track, or do you also want to 
> > build this great new thing?
> > 
> Hmm, I don't know - I think your ideas make mostly sense (we already
> discussed some of them in the past), but for me these are technical
> details (I don't say that they are not important). But I think, we need
> a vision for 3.0 - what do we want to achieve?
> Now, most of the alternatives to Cocoon have one thing in common: they
> are easy too learn and you can start quickly (and most of them have the
> "start quick and fail later" problem but that's another story). Whereas
> if you want to use Cocoon, you can't start right away. There is so much
> to learn, so many different files you have to write/adjust.
> Why do managers love Struts or JSF? It's a "standard" but even more
> important, they have tools. Fancy tools sell your product, that's the
> bitter truth. And I have the feeling, that products, that don't have
> tools but are "just cool", will not be used anymore (it's just a feeling).

Hello Carsten, Sylvain,

I can tell you about my situation. We have developed a lot of applications based
on Cocoon, first of all we have pointed our CMS on Cocoon Technology. In the
last 2 years we started using Cocoon also for creating complex applications with
CForms. Before, we just used Cocoon as container for Authentication, Content
retrieval, aggregation, composition and all you can do with XSP.
CForms seems to be the best for us - we are having a lot of Cocoon know how,
CForms is fast to develop (in comparison with Struts) and everything could be
But we've forgotten something - and this was becomings my worst decision ever
made. The customer has a dedicated hosting environment, BEA 8.1, Apache, Oracle
and SUN JDK 1.4.2 all on Solaris / Sparc.
Usual stuff, but Cocoon runs very slow in this environment, especially CForms
and the newer JXTransformer. Tested on Intel Hardware or using Tomcat would
solve the problem. Ive done a lot of performance optimizing but however, it
never runs as fast as on JBoss. Some CForms Applications on BEA 6 with JDK 1.3
are running with an evil Cocoon SVN Checkout because this is the first version
where the Rhino stuff is working but the last where Cocoon runs on JDK 1.3.
Another point are reliable API's. It is worse enough, that no Template System is
marked final and even CForms is still beta. It IS worse, that you wont be able
to run your application on the next Cocoon Version. We still can not switch some
applications from 2.1.6 to the actual version because of changes in Cocoon.
CForms has Version 1, 2 and 3 - where discussed on the last GetTogether in Gent
the Version 1 becomes the final Version. 
What do you expect from your users? Throw away all stuff done before?
THats the point why stuff like JSF is much cooler in some cases then Cocoon. You
can use many implementations (actutal SUN, Apache, Oracle) if one seems buggy,
the API is RELIABLE and you can do updates of the implementation with small test
efford. If you have some cool tools like NitroX, I think it is more pragmatic to
use JSF with a faster result then using CFOrms for that.
For me as developer I have learned that an unreliable API might be faster at the
beginning, but will kicks your ass afterwards.
I wont use any Cocoon API again without beeing sure the API is marked final and
the used Cocoon Version has no bugs in that part so I can use it in that case if
a newer Cocoon Version has changed the API.

The first sentences from Silvain are absolutely correct - it is necessary to
jump on the bandwagon and support the newest development mythologies like:
POJOs, Ajax, IoC, DI and so on.
Especially an excellent Ajax Support is very important, I think this trend will
tend even more and more Swing / Client Applications to be ported to the web.
The newest trends in J2EE are also important: POJOs, support of enterprise grade
persistence (EJB3.0) instead of no-standard-implementations, switch the Avalon
Container (sorry, dont know how far you guys are) to Spring container or another
lightweight container platform, think about a standard interfacing to get
reliable APIs, support of trails ( or a cocoon
implementation, better interaction between other enterprise J2EE stuff like
jetspeed or pluto and definitely a better test or use on weblogic, websphere and

Just dont be angry about my receiveables, this are just my 2 cent after about 5
years Cocoon development.


View raw message