> -----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
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
