Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 81779 invoked by uid 500); 10 Mar 2003 09:35:57 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 81759 invoked from network); 10 Mar 2003 09:35:56 -0000 Received: from unknown (HELO mail.cbim.it) (212.131.130.82) by daedalus.apache.org with SMTP; 10 Mar 2003 09:35:56 -0000 Received: from cuprouter.cbim.it (cuprouter.cbim.it [192.168.4.10]) by mail.cbim.it (8.11.6/8.11.0) with ESMTP id h2A9vos07635 for ; Mon, 10 Mar 2003 10:57:50 +0100 Received: from cbim.it (caterina.cbim.it [192.168.4.42]) by cuprouter.cbim.it (8.9.3/8.9.3) with ESMTP id KAA13376 for ; Mon, 10 Mar 2003 10:38:29 +0100 Message-ID: <3E6C5CA7.10206@cbim.it> Date: Mon, 10 Mar 2003 10:36:39 +0100 From: Ugo Cei Organization: C.B.I.M. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: DO NOT REPLY [Bug 17673] - sendPage function in Flow causes an NPE. References: <20030310093013.25108.qmail@nagoya.betaversion.org> In-Reply-To: <20030310093013.25108.qmail@nagoya.betaversion.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N bugzilla@apache.org wrote: > ------- Additional Comments From u.cei@cbim.it 2003-03-10 09:30 ------- > I have a patch (attached) that hopefully fixes this bug. What it does is to wrap > the call to this.rootNode.invoke in o.a.c.components.treeprocessor.TreeProcessor > with a call to CocoonComponentManager.startProcessing (before) and to > CocoonComponentManager.endProcessing (after), mimicking the behavior of > o.a.c.Cocoon. Looks like this morning I enjoy talking to myself ;-). One brief note: in order to fix that bug, I had to make two more changes, adding defensive null checks in AbstractEnvironment.release: if ( null != source && null != sourceResolver) this.sourceResolver.release( source ); and CocoonComponentManager.leaveEnvironment: if (desc != null) { desc.removeLastSitemapConfiguration(); } Is this a case of not enough defensive programming or do the NPEs that occur when the checks are not in place a symptom of a problem somewhere else that the checks merely hide from view? Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: +39.0382.525100 - E-mail: u.cei@cbim.it