cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: How to register MockProcessInfoProvider?
Date Mon, 30 Jul 2007 10:02:26 GMT
Carsten Ziegeler skrev:
> Grzegorz Kossakowski wrote:
>> After exploring code for a while I came to conclusion that I need to
>> implement stub implementation of HttpServletRequest, HttpServletResponse
>> and ServletContext that will forward to Cocoon's corresponding classes.
> Hmm, or the other way round - if the tests would create httpservlet
> classes first, perhaps the current cocoon environment wrappers could
> just be used to wrap them.
>> Additionally, I've read /[RT] Ditching the environment abstraction/
>> thread[1] where Daniel proposed to switch to standard servlet interfaces
>> from Cocoon's own ones. I've seen that several folks were rather
>> reluctant[2][3] to allow these changes. There were concerns raised[4]
>> that some methods in our interfaces has no counterparts in Servlet API
>> interfaces.
>> Since ProcessInfoProvider operates on interfaces from Servlet API I
>> wonder if community's standpoint changed to date.
>> Carsten, it was you who introduced ProcessInfoProvider interface, could
>> you comment?
> It's a long time ago....well, the basic idea was that, as Daniel pointed
> out in the mentioned thread, there are a lot of libraries/code out there
> which require servlet classes (req/resp/context) are required.
> The ProcessInfoProvider is a bean which just delivers these and does
> internally the required wrapping or unwrapping. In addition this creates
> a migration path as new stuff can be written which depends just on the
> servlet api and the bridge to the old stuff is this info provider.
> I totally agree that we should remove our own environment as soon as
> possible, but this would create a lot of incompatibilities (as outlined
> in one of those threads).

"A lot of incompatibilities" is an exaggeration. If we just let or 
Request, Response, Session and Cookie extend the corresponding http 
servlet ones, we would just get a few minor incompatibilities that IMO 
would be rather minor in comparison with the benefits of using a 
standardized API.

> The biggest is that req.getSession() returns a
> o.a.c.e.Session currently and with switching to the servlet api it
> becomes a httpsession.

As o.a.c.e.Session in the above proposal would extend HttpSession an 
object implementing o.a.c.e.Session can still be returned, so it 
shouldn't be such a big deal.

I took a more detailed look at it, we would need to change the following 
methods in Request:

Cookie[] getCookies();
InputStream getInputStream();
Session getSession(boolean create);
Session getSession();

I discussed the session methods above. The o.a.c.e.Cookie is a little 
bit worse as it is an interface and javax.servlet.http.Cookie is a 
class. But we could let o.a.c.e.http.HttpCookie (which is the only 
implementation of o.a.c.e.Cookie) extend javax.servlet.http.Cookie and 
just remove o.a.c.e.Cookie (which has exactly the same signature as 
javax.servlet.http.Cookie). The getInputStream method needs to return a 
ServletInputStream instead of an InputStream. As the 
o.a.c.e.http.HttpRequest.getInputStream returns a ServletInputStream 
anyway, I don't think it would lead to any problems.

Response and Session lacks a few methods from their http servlet counter 
parts. We could let them throw unsupported operation exceptions.

So to summarize, it would be a great benefit to let our environment 
abstractions extend the http servlet ones and the cost would be low. So 
it is time to do it.


View raw message