Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46A67899.9020008@apache.org>
Date: Wed, 25 Jul 2007 00:09:29 +0200
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 2.0.0.5 (X11/20070716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: How to register MockProcessInfoProvider?
References: <46A5CBBC.8040604@tuffmail.com> <46A61B06.6010002@apache.org>
 <46A61EF4.3060300@apache.org>
In-Reply-To: <46A61EF4.3060300@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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
http://reflectingonthevicissitudes.wordpress.com/