Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 98201 invoked by uid 500); 5 Jun 2003 15:20:04 -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 98133 invoked from network); 5 Jun 2003 15:20:02 -0000 Received: from onramp.i95.net (205.177.132.17) by daedalus.apache.org with SMTP; 5 Jun 2003 15:20:02 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.9/8.12.9) with ESMTP id h55FK207027213 for ; Thu, 5 Jun 2003 11:20:03 -0400 Message-ID: <3EDF5FE4.3090608@apache.org> Date: Thu, 05 Jun 2003 11:21:08 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Unusual behaviour with References: In-Reply-To: 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 Geissel, Adrian wrote: > Hi, > Firstly, I should have mentioned that we're running Cocoon 2.0.4 > > Now for some more information - and it's really bizarre! > > The stylesheet "query-to-options.xsl" contains two comments before the first > element: > one for the copyright, and > one explaining its purpose. > > *REMOVING* these comment sections causes the offending exception, and > associated spinning thread, to disappear! Very bizarre! To be sure, the > comments are well formed, and do not contain and wierd or unusual > constructs, other than two comments placed before the root element (but > then again, never experienced any issues doing this upto now). > > Any ideas? > You are probably the victim of an XML parser getting more strict with the XML spec. Having comments outside the root element of a document is _not_ well formed, and any XML parser is free to reject that. If you move those comments INSIDE the root element, you should also lose the exceptions. The separate issue that needs to be addressed is why is a thread spinning if there is an error with a document? Cocoon needs to be able to handle this failure more gracefully and shut down any threads that were created for processing purposes.