cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <>
Subject Re: We need a detailed comparison with Struts
Date Thu, 13 Jun 2002 13:50:32 GMT
From: "Stefano Mazzocchi" <>
> Piroumian Konstantin wrote:
> >
> > Hi!
> >
> > I have alsmost 2 years' experience in the XML (Cocoon) vs. JSP (Struts)
> > fight in our company, wrote several documents related to
> > Cocoon/Struts/Self-implemented framework comparison and I'd like to tell
> > that all the arguments for Cocoon break on the following:
> I think this calls for some answers.
> >         - Cocoon has portability problems while JSP is supported
natively by
> > many/several App Servers and some of them have Struts already integrated
> I never heard of this. Can you please indicate what are those
> 'portability problems' you have experienced? (you or the people you
> talked to)

I should have said 'compatibility problems' instead, sorry if it was

I've tried Cocoon on Tomcat 3.x/4.x, WebLogic 5.1/6.0/6.1/7.0, IONA iPortal
app servers and only on Tomcat 4.x I could simply deploy the cocoon.war with
no problems. Usually the problems came from the XML parsers, sometimes from
Cocoon (getRealPath() from a WAR deployment), there were some other problems
too (e.g. with JSPEngine, OutOfMemoryException during deployment on IONA App
server, etc.).

But, Struts is either not perfect in this: I've been getting exceptions from
XML parser during deployment on IONA iPortal.

The only server that has minimum problems with Cocoon is Tomcat 4.x (except

> >         - XSP is not standart while JSP has a specification,
> > tests, etc.
> Granted.
> >         - JSP is much more popular than XSP and there is a lot of
> > purpose JSP taglibs available
> Granted.
> >         - Cocoon changes to quick - we had a lot of problems with C1->C2
> > that experience frightened our architects
> Granted. I'm personally aware of the fact that many people got seriously
> hurt by this migration. At the same time, Cocoon1 had too many design
> issues and there was no way around this.
> At the same time, the Cocoon dev community learned a lot of lessons and
> if somebody believes this is going to happen again (with books coming
> out of the door) they are simply underestimating the amount of money
> that several companies/organizations are investing in Cocoon (think NASA
> and you know what I'm talking about)
> >         - Cocoon's codebase is much more complicated than Struts' and
> > depends/uses a lot of 3rd party stuff
> Granted.
> >         - Cocoon requires knowledge of many different
> > (Java/Servlets, XML, XSLT, XSP, Sitemap, JavaScript - for flow, and some
> > others, optionally) while Struts is much simpler in usage and requires
> > knowledge only of JSP/Servlets and has a relatively simple configuration
> > file in XML.
> Absolutely.
> >         - and at last, not every application needs multimedia output
that is
> > one of the coolest features of Cocoon
> That's for sure.
> > The above is not my personal opinion, but was gathered in a lot of
> > discussions with my collegues and our experience either with Cocoon or
> > Struts.
> Ok
> > My personal opinion is that if Cocoon had no compatibility problems
> > those are JAXP and classloader problems and rarely problems come from
> > Cocoon's request/response abstractions) then it would be much better for
> > middle/high level of complexity web applications than Struts.
> I feel that Cocoon is still way too weak from the flow description
> perspective in order to seriously compete with any web-app oriented
> frameworks.

I am not agree with this. Maybe there are some webapp frameworks that are
better than Cocoon for webapps, but I would not say that Struts is one of

Everything that can be done by Struts is possible with Cocoon.

I can provide a sample both: for Struts and Cocoon - there will be not much
difference. More over, Cocoon-based sample will have a sitemap shorter than
struts-config, because of wildcard matching, better parametrized actions (an
Action in Struts can have only one(!) parameter).

> Cocoon is and remains focused on publishing (that is: declarative web
> serving) until we have a way to describe procedural flows. See more
> below.

I'm not going to judge if it's a good approach, but we have internal
redirects, we have actions and we can use sitemap resources to have separate
flow (actions + redirects) and publishing (resources). I am ready to provide
comparison samples if needed.

And I don't think that this approach is worse than Struts' - it's almost the
same. Look at any sample struts-config.xml and you'll understand what I say.



> So that everyone can draw their own conclusions afterwords.
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message