Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 26363 invoked from network); 20 Sep 2007 16:13:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Sep 2007 16:13:17 -0000 Received: (qmail 55135 invoked by uid 500); 20 Sep 2007 16:13:07 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 55069 invoked by uid 500); 20 Sep 2007 16:13:07 -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 55058 invoked by uid 99); 20 Sep 2007 16:13:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Sep 2007 09:13:07 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.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; Thu, 20 Sep 2007 16:15:04 +0000 Received: from [192.168.0.125] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id 139CDA3295 for ; Thu, 20 Sep 2007 12:12:41 -0400 (EDT) Message-ID: <46F29C09.2030201@apache.org> Date: Thu, 20 Sep 2007 18:12:57 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Demystification of pipelineComponent trouble References: <46F1A121.8060604@tuffmail.com> <46F1AAC0.7030600@gmx.de> <46F1AECE.4000906@reverycodes.com> In-Reply-To: <46F1AECE.4000906@reverycodes.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Vadim Gritsenko pisze: > Joerg Heinicke wrote: >> On 19.09.2007 18:22 Uhr, Grzegorz Kossakowski wrote: >> >>> As you see, this pipeline just process simple JX template that tries >>> to access one variable >>> (status.myTasks) and fails at this point. It must fail (by throwing >>> NPE) because there is no >>> status.myTasks variable in OM! It's the flowscript code from myBlock1 >>> that is responsible for >>> setting it and that's why the only valid way to test my sample: >> >> Whether there is a variable set or not, a NPE is never good sign. >> Shouldn't this case be handled? Spring for example throws a >> NullValueInPathException instead. > > No. No to exception :) > > I suspect in this particular case (CTemplate) no exception should be > thrown at all: as far as I understand, Cocoon 2.1 will just return empty > (or null) value, but will not throw an exception. Examples: > > ${foo}, ${cocoon.foo}, ${continuation.foo} > > all return empty value, no exception. That's problem with Jexl not CTemplate or OM (actually it is a Jexl who throws NPE). If you try this expression: ${cocoon.foo.size()} it will throw NPE because size() is internal Jexl's function that is tried to be applied to null value. I'm with all of you expecting 0 or null in this case but it's really Jexl's problem. That's the one amongst many reasons why I much prefer JXPath :P -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/