cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: How to register MockProcessInfoProvider?
Date Tue, 24 Jul 2007 15:47:00 GMT
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). 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.

Personally I would strongly suggest to leave this stuff as it is and
release 2.2 and see what happens.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message