cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Ditching the environment abstraction
Date Tue, 13 Dec 2005 21:20:22 GMT
Ralph Goers wrote:
> Daniel Fagerstrom wrote:
>>The servlet set of apis is allready an abstraction, we have due to 
>>historical circumstances another abstraction of the same concepts. To 
>>me the abstractions look fairly similar, except for the Cocoon 
>>aditions that have been mentioned. What am I missing more specifically?
> What exactly are the sevlet apis an abstraction of? 
>>We could have compablity wrapper. Question is do we want to simplify 
>>or not?
> What, exactly are we simplifying?  There is no way that we won't always 
> have a "real" HttpServletRequest.  AFAICS there is no way that we can 
> just use it.  So what would replace the existing Request object?  In 
> order to understand this I really need to know exactly what the new 
> object would be.
Hmm, now, one possible way of simplifying could be to extend the
HttpServletRequest/Response objects, so if you need an
HttpServletRequest somewhere you directly have it. But for example our
Response object does not provide access to the outputstream, and I'm
sure even if we extend the HttpServletResponse interface, we want to
block direct access to the output stream (by throwing an exception).
And there might be other examples for this - so in the end if you need a
real servlet response object you can't use our response object as we
block some operations.
Currently, we store the original http servlet request/response objects
in the object map next to our own versions of it. So if you really need
the original objects, you can look them up.

I have the feeling that changing this does not buy us something and that
does it not make life easier - I might be wrong though. Now, I still
think we should make the request/response objects more easily accessible


Carsten Ziegeler - Open Source Group, S&N AG

View raw message