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 somehow. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
