Return-Path: X-Original-To: apmail-cocoon-dev-archive@www.apache.org Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 83AF19B76 for ; Tue, 26 Feb 2013 15:37:22 +0000 (UTC) Received: (qmail 66559 invoked by uid 500); 26 Feb 2013 15:37:22 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 66466 invoked by uid 500); 26 Feb 2013 15:37:22 -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 66457 invoked by uid 99); 26 Feb 2013 15:37:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2013 15:37:21 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [78.134.5.44] (HELO rovere.tirasa.net) (78.134.5.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2013 15:37:15 +0000 Received: from localhost (localhost [127.0.0.1]) by rovere.tirasa.net (Postfix) with ESMTP id C7579180A52 for ; Tue, 26 Feb 2013 16:36:53 +0100 (CET) X-Virus-Scanned: amavisd-new at tirasa.net Received: from rovere.tirasa.net ([127.0.0.1]) by localhost (rovere.tirasa.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALfLjMbwSc9k for ; Tue, 26 Feb 2013 16:36:47 +0100 (CET) Received: from [192.168.0.2] (mogano.tirasa.net [192.168.0.2]) by rovere.tirasa.net (Postfix) with ESMTPSA id 00597180A47 for ; Tue, 26 Feb 2013 16:36:46 +0100 (CET) Message-ID: <512CD68F.1080708@apache.org> Date: Tue, 26 Feb 2013 16:36:47 +0100 From: =?windows-1252?Q?Francesco_Chicchiricc=F2?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: REST view and weird error References: <512736A1.30704@gmail.com> <512B463F.3040905@gmail.com> <512B4CCE.8080503@gmail.com> <512B62CE.4050800@gmail.com> <512CADEA.2020103@gmail.com> <512CC4F2.7080801@apache.org> <512CC5D5.9080505@gmail.com> In-Reply-To: <512CC5D5.9080505@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 26/02/2013 15:25, Thorsten Scherler wrote: > On 02/26/2013 03:21 PM, Francesco Chicchiricc� wrote: >> On 26/02/2013 13:43, Thorsten Scherler wrote: >>> On 02/25/2013 02:10 PM, Thorsten Scherler wrote: >>>> ... >>>> Passing pipeline parameter as attribute: key=cocoon, value=[FAILED >>>> toString()] >>>> >>>> in MessageFormatter.arrayFormat. >>>> >>>> still investigating >>>> >>>> salu2 >>>> >>> Actually you can see it if you start the cocoon-sample block and request >>> http://localhost:8888/controller/abc/foo?reqparam=1 >>> >>> >>> SLF4J: Failed toString() invocation on an object of type >>> [java.util.HashMap] >>> java.lang.StackOverflowError >>> at >>> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:631) >>> at java.lang.StringBuilder.append(StringBuilder.java:224) >>> at >>> org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312) >>> >>> at java.lang.String.valueOf(String.java:2902) >>> >>> It actually happens in STRenderer >>> [...] >> Hi Thorsten, >> as you have already found, the problem is the "cocoon" entry in the >> sitemap's ObjectModel, always passed among parameters. >> >> I have been able to actually print the content of the "cocoon" entry >> via common-collection's MapUtils: >> >> if (entry.getValue() instanceof Map) { >> MapUtils.verbosePrint(System.out, null, parameters); >> } else { >> System.out.println(entry.getValue()); >> } >> >> I am about to commit a fix for the issue in STRenderer you've reported >> above based on the usage of MapUtils#verbosePrint() > Nice you are a "monstruo". Hem, guess you mean "mostro" (a.k.a. monster) - I'll take as a compliment ;-) Anyway as per r1450217 the StackOverflowError is removed from STRenderer. > Let us see whether that gets rid of the redundant data as well. I've been exploring a bit the various call and I think that this duplication might be generated when intra-pipeline calls (e.g. "servlet:/") are issued. Regards. -- Francesco Chicchiricc� ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/