Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 88243 invoked from network); 24 Jul 2007 15:30:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Jul 2007 15:30:55 -0000 Received: (qmail 72223 invoked by uid 500); 24 Jul 2007 15:30:55 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 72126 invoked by uid 500); 24 Jul 2007 15:30:54 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 72114 invoked by uid 99); 24 Jul 2007 15:30:54 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 08:30:54 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jul 2007 08:30:52 -0700 Received: from [192.168.0.129] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 6A4CEA3238 for ; Tue, 24 Jul 2007 11:30:30 -0400 (EDT) Message-ID: <46A61B06.6010002@apache.org> Date: Tue, 24 Jul 2007 17:30:14 +0200 From: Grzegorz Kossakowski 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> In-Reply-To: <46A5CBBC.8040604@tuffmail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Grzegorz Kossakowski pisze: > Hi, > > I'll give you some background to my problem. I use ProcessInfoProvider > for accessing environmental data because I've read[1] that it is a > proffered way to do this in Cocoon 2.2. Now, I would like to write tests > for Spring beans depending on ProcessInfoProvider. I thought that it > makes sense to provide mock implementation and register it in > AbstractTestCase, similarly to how settings is registered; see my commit > r558983[2]. > > I think, that it should work well and I think that it makes sense to > register ProcessInfoProvider implementation in AbstractTestCase because > this component provides access to environment and should be easily > available for every test. The problem is that ProcessInfoProvider refers > to javax.servlet.http.HttpServletRequest and in AbstractTestCase request > is created with type org.apache.cocoon.environment.Request. > > I'm puzzled what to do in such case, do you have any suggestion? > > [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/68706 > [2] http://article.gmane.org/gmane.text.xml.cocoon.cvs/24845 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. 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? [1] http://thread.gmane.org/gmane.text.xml.cocoon.devel/59035 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/59143 [3] http://article.gmane.org/gmane.text.xml.cocoon.devel/59163 [4] http://article.gmane.org/gmane.text.xml.cocoon.devel/59118 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/