cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: [C2] objectModel issues
Date Fri, 16 Mar 2001 17:20:56 GMT
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

- donald

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

View raw message