Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 7776 invoked by uid 500); 12 Feb 2003 16:01:32 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 7720 invoked from network); 12 Feb 2003 16:01:31 -0000 User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Wed, 12 Feb 2003 11:04:16 -0500 Subject: Fault tolerance... From: Ben Young To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N In my current work with the aggregation option in Cocoon 2.0.4 it seems that the aggregation options are not very fault tolerant. If one of the map:part's of my map:aggregate section points to a file that does not exist, all map:part's after that one do not get returned even if their files exist. With a cinclude transformer the error is a bit worse. If the file requested does not exist in the pipeline, I get a NullPointerException from line 180 in the CIncludeTransformer.java. That line contains the source.recycle() call. Since the source is never created, there is nothing to recycle. Hence the error. Would it be possible to make the map:aggregate continue on it's merry way even if one of the map:part's doesn't resolve to anything? Would it also be possible to add some fault tolerance to the CincludeTransformer? It seems to that the cinclude's done using the cocoon:// protocol don't follow any map:redirect-to's. That's probably somewhat unrelated, but worth mentioning I guess. 8o) Thank you for your thoughts and time, Ben --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: