cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2] objectModel issues
Date Mon, 19 Mar 2001 07:29:06 GMT
Berin Loritsch wrote:
> Donald Ball wrote:
> >
> > On Tue, 13 Mar 2001, Berin Loritsch wrote:
> >
> > > One of the ideas behind Cocoon is the ability to use it in
> > > different contexts like: JAMES Mailet, Servlet, Avalon Block,
> > > CommandLine, etc.  One of the things that we do that makes
> > > Cocoon inextricably tied to the Servlet API is the use of
> > > the HttpServletRequest (or even HttpRequest) objects in
> > > logicsheets, actions, and any place we want to get a request
> > > parameter.  This is not consistent with the Separation of
> > > Concerns pattern in use within Cocoon.  We have specified
> > > several interfaces that allows Cocoon to abstract out the
> > > interface from the implementation.
> > >
> > > What we have is a mess on our hands in this regard, because
> > > it forces Cocoon to be a Servlet, and only a Servlet.  Cocoon
> > > needs to specify the interfaces that it will allow internal
> > > components to use.  If that means redefining the HttpServletX
> > > interfaces to be Cocoon specific, then we need to do that.
> > > It will also allow us to have the HttpServlet22 and HttpServlet23
> > > classes in the archive at the same time.  That will allow the
> > > webapp to be compiled once and deployed in any Servlet 2.2+
> > > container--without recompiling.
> > >
> > > I would propose simplifying the Request/Response interfaces
> > > a little bit, and merging the Parameters and Attributes into
> > > one access point.  Also, by using this approach, we won't need
> > > to worry about having the Servlet jar in the classpath.
> >
> > it sounds good on paper, but i fear the devil in the details. are you
> > thinking of providing, um, context-independent API's for request
> > parameters, http headers, cookie stuff, and session stuff? or just request
> > stuff?
> That's part of the issue.  I really don't care if it's a wrapper class
> around the Servlet interfaces.  We already have that--but I wanted those
> wrapper classes to implement Cocoon interfaces, that allows new Environment
> implementations.  We have a FileSystem Environment and a Servlet Environment.
> I just want to complete the work that is already started.

In summer 2000 Stefano, Ricardo and I were talking about it at Stefano's
house. We've choosen to use the Servlet API as a base because 80%+ of
C2's use will be as a servlet. But you are right we ended up with
wrappers because we had to protect ourselfs from using harmfull methods
like messing with the output stream. And we further need to intercept
calls like sendRedirect to signal "end of production" to the
ResourcePipeline. As with the Servlet spec. 2.3 it started to get
complicated because of the need to extend the Wrapper classes supposed
to be
according to the spec. (at those times redirecting in Catalina wasn't
working if
your Response object wasn't derived from ResponseWrapper).

If I understand you correct you're proposing to consolidate all the
Request/Response wrappers we have so far into Cocoon interfaces for
Request and Response as base for all Environments C2 can work in, right?


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

View raw message