> -----Original Message----- > From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 4:32 AM > To: [EMAIL PROTECTED]; Sylvain Wallez; > [EMAIL PROTECTED] > Subject: Re: We need a detailed comparison with Struts (XML/REST > integration?) > > > On Monday 10 June 2002 10:23, Sylvain Wallez wrote: > >. . . > > 4 - Can we integrate Stuts and Cocoon ? > > -------------------------------------- > > The JSP part of Struts can certainly be integrated into > Cocoon using the > > JSPGenerator. What about the controller part (i.e. the servlets) ? > >. . . > > Rings a bell here, cause I'm thinking along the same lines > between Enhydra > (www.enhydra.org) and Cocoon. > > How about using these (struts, enhydra, etc.) as XML-based > back-ends to a > Cocoon presentation front-end? > > I'm thinking of Cocoon relaying user HTTP requests to the > back-end, and the > back-end replying with XML documents representing the > "logical contents" of > pages (see also [1]). > > The back-end would be fully testable with anteater, JUnit/HTTPUnit or > something using HTTP/XML interactions, and the Cocoon > front-end would be > nicely decoupled and care only about the presentation layer. > > Any comments? First-hand experiences? These are a bunch of comments about security in Cocoon, but relate to how things might be different if Cocoon was wrapped with a custom JSP or custom Avalon controller. Some of this may be possible (even documented) already, your comments are welcome on any of this! I've been wondering how it would be possible to integrate the container-managed security of Tomcat with the functionality of Cocoon. The reason for this would be to grab authentication information from the container hierarchy, which in my case would be Tomcat in turn relying on JBoss 3. JBoss3 has an extremely comprehensive security system based on JAAS that also manages access control of the EJBs, so complete single sign-on and integration with other authentication providers (such as W2K/Kerberos) is much easier to achieve. Because container-managed security relies on deployment descriptors in web.xml, the ideal situation would be to not rely on constantly merging our local web.xml changes into Cocoon's web.xml each time we want to bring ourselves up to date with the latest version of Cocoon. It seems like cleanest answer to this is to generate the .war in our build, then make Cocoon a client of that. I bring all this up here because it might be very useful to have either or both of a Cocoon tag for Struts or a Cocoon component for Avalon. (I'm familiar with JSPGenerator, but that makes Cocoon the parent to JSP, and I am considering the other way around for migration purposes...) My other consideration for these facilities in Struts and Avalon is for managing complexity. I'm not entirely comfortable yet with having a sitemap and custom actions be the controller for the entire production deployment. It seems rather error prone and difficult for a developer to prove their changes are correct without extensive modeling of the sitemap as a state machine. Modeling is great if you have a lot of time or a fair number of rock stars on the team, but burdensome for small shops with limited resources and less experienced staff. OTOH, anytime end-user financial information (credit cards) is involved, liability is enormous and the confidence level has to be there. So it would follow that it will be difficult for smaller shops to build commerce applications on Cocoon since they don't have the resources to prove their sitemaps. The subsitemap for portals is a good example of what I am talking about. It's necessarily complex, and strikes me of languages that require a rather considerable rewrite when changes are needed and the original author is not available (i.e. Lisp and co., many forms of Perl, etc.) I see this sitemap as something that ours would grow up to, but handing that off to someone else to own is going to be really tricky. And again, financial information complicates that issue even further because any change absolutely has to be right. It's true that flowmaps may solve all of these issues, and I'll probably spend a few hours today considering them, but I need to be integrated with the portal at some point and I'm not sure how that is going to be done. Finally, consider how existing applications could have Cocoon applied against them. The Struts/Avalon integration components would provide a segue for companies to start using Cocoon today without it being perceived as an all-or-nothing proposition. Cocoon has everything to gain by starting off as a subordinate to legacy technologies, since once developers understand that they don't need their current framework any more, they can simply shed it. In the cases where they do need the framework though, it's the difference between using some of Cocoon or none at all. And the more visibility and use that Cocoon can get, the further it will go. $0.03, FWIW... -b > > -Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
