cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject RE: Dispatcher/Adapter
Date Tue, 12 Feb 2002 20:10:05 GMT
On Tue, 12 Feb 2002, DZIEMBOWSKI,KINGA (HP-NewJersey,ex2) wrote:

> For the HttpServletRequest/HttpRequest/Request problem - the fact that I am
> not using any other methods that get/setAttribute does not mean anything.
> The discussion is about fundamentals not specific usage in the simplistic
> example. The Adapter or Dispatcher may need to access some information
> associated with the transport on which the request was sent, including for
> example InputStream for some reason. When you expose some public interface
> you try to make this as usable as possible with the minimal number of
> dependencies. My preferred choice will be HttpServletRequest and I said
> already why. I am able to compromise this to use Cocoon abstraction but it
> cannot be Request ( as it is today ) it does not expose all
> HttpServletRequest definitions.

Well, again. This discussion has been held a year ago. Originally the
Cocoon Request interfaces *were* based on the ServletRequest interfaces
but over the time the decided has been to move onto it's own
implementation to allow a more generic abstraction of an Environment
(which is good IMHO). So, I don't really want to go the same path again
and I don't see your objection does really matter in the Cocoon
environment to use the original HttpServletRequest or the abstracted
Cocoon Request.

I also don't see why the Cocoon request has to "expose all
HttpServletRequest" as the name is too specific for Servlets and that's
what Cocoon wants to avoid to show that it has its own abstraction of an
Environment. The objectModel contains the original environmental objects
IRRC for parts which needs to know and run in a specific environment.
The Cocoon core itself will and should not be be bound to any specific

Components which needs the specific environmental objects will not run
in other environments (i.e. Commandline). This was very clear from the
beginning of the design of this abstracted environment (and to tell you
the truth, everybody knew there might be components with those needs but
we avoided those being part of the distributions so far). And thus the
more a Component can rely on the most abstracted environment the more
they can be reused in other environments as more of those will be
implemented anytime.

The way to go was to implement a set of methods in the abstract
environmental interfaces and add more if there will be a requirement.


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

View raw message