cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Prante <>
Subject Re: [C2] objectModel issues
Date Wed, 14 Mar 2001 10:17:15 GMT
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.  

I think this is not really a mess being a component on server side ;-) The 
usage of request parameters directly from the Servlet API is very convenient, 
especially for request parameters and sessions. Java servlet programmer will 
ask for this possibility of Servlet API access if they migrate to Cocoon. So 
Cocoon should provide a thing like this.

Since I don't know the functionality of the other contexts (James, Avalon 
Block etc.) regarding sessions, I would suggest to examine the power of 
manipulating HTTP session objects together with request/response 
parameterizing, and how this can be done in Cocoon contexts. I'd like to 
spend some time on Cocoon HTTP session logging and monitoring in the next few 
weeks, and if I knew the perfect way to do this for other Cocoon contexts 
too, it would be great.

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

I am a little bit confused because "Cocoon specific HTTP interfaces" sounds 
like getting off the road. I really do not encourage throwing away 
functionality of the HttpServlet API 2.3+. But I really can't even imagine 
that this is Berin's intention ;-)

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

Please excuse me if I misunderstood. So what kind of HttpServlet 
functionality will be available from Cocoon? What functionality will a 
standard Cocoon context provide at least? I think of sessions, requests, 
responses, cookies...

How about ensuring that every Cocoon context provides equivalent 
functionality regarding to the HttpServlet 2.3+ API? That means keeping the 
CocoonServlet, and introducing some new access point classes for the other 
contexts in org.apache.cocoon? This won't disable the writing of HttpServlet 
dependant logicsheets, and other context-specific logicsheets, which might be 
developed in the future. 

Another idea of mine is context-dependant compilation of built-in 
logicsheets. If a context doesn't exist, it need not to be initialized and 
the logicsheets using this context could be ignored at Cocoon start-up 
time, right? 


Jörg Prante
Sevenval AG (HRB 32757) e-business marketing technologies
D-50667 Köln . Alter Markt 36-42
Fon +49 221 65007-0 . Fax 4249891 .

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

View raw message