cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: We need a detailed comparison with Struts (XML/REST integration?)
Date Mon, 10 Jun 2002 10:58:50 GMT

> -----Original Message-----
> From: Bertrand Delacretaz []
> Sent: Monday, June 10, 2002 4:32 AM
> To:; Sylvain Wallez;
> 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 
> ( 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

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...


> -Bertrand

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

View raw message