From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> > 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 misleading. 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 4.0.3). > > > - XSP is not standart while JSP has a specification, compatibility > > tests, etc. > > Granted. > > > - JSP is much more popular than XSP and there is a lot of general > > purpose JSP taglibs available > > Granted. > > > - Cocoon changes to quick - we had a lot of problems with C1->C2 and > > 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 technologies/things > > (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 (usually > > those are JAXP and classloader problems and rarely problems come from > > Cocoon's request/response abstractions) then it would be much better for any > > 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 them. 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. Konstantin <snip/> > > 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. > <[EMAIL PROTECTED]> Friedrich Nietzsche --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
