cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: How to register MockProcessInfoProvider?
Date Tue, 24 Jul 2007 22:09:29 GMT
Carsten Ziegeler pisze:
> 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.

What about getParameters() sort of methods that enable you to have expressions like cocoon.request.parameters.param1

Since ProcessInfoProvider returns implementation of HttpServletRequest there is no access
to these methods. Any idea on this?

Grzegorz Kossakowski

View raw message