Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 3247 invoked from network); 1 Jun 2006 02:52:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jun 2006 02:52:56 -0000 Received: (qmail 24658 invoked by uid 500); 1 Jun 2006 02:52:53 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 24597 invoked by uid 500); 1 Jun 2006 02:52:53 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 24577 invoked by uid 99); 1 Jun 2006 02:52:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 19:52:53 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [63.208.196.171] (HELO outbound.mailhop.org) (63.208.196.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 19:52:52 -0700 Received: from cpe-071-070-164-031.nc.res.rr.com ([71.70.164.31] helo=[192.168.0.142]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FldIV-0005o2-PG for dev@geronimo.apache.org; Wed, 31 May 2006 22:52:31 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.70.164.31 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: hogndos Message-ID: <447E566F.4080603@hogstrom.org> Date: Wed, 31 May 2006 22:52:31 -0400 From: Matt Hogstrom User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: The evil of mixed content rears its ugly head in the config.xml local-attributes-1.1 schema References: <7B5BA7F4-4B88-4467-AAA4-7B95C0770AE4@yahoo.com> In-Reply-To: <7B5BA7F4-4B88-4467-AAA4-7B95C0770AE4@yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I think waiting makes sense except I think the ugly message will confuse users. Is there a fix to at least eliminate this message in the interim ? David Jencks wrote: > Now that we have a schema for config.xml it's become more painfully > obvious that we are putting mixed content into the attribute elements of > config.xml. You can override an xml-attribute in a gbean such as the > elements in the builders by putting the override > xml right into an attribute element in config.xml. This works great and > we use it in the tck setup. > > The schema validation we now seem to be doing is emitting warnings like: > > Booting Geronimo Kernel (in Java 1.4.2_09)... > Warning: validation was turned on but an org.xml.sax.ErrorHandler was not > set, which is probably not what is desired. Parser will use a default > ErrorHandler to print the first 10 errors. Please call > the 'setErrorHandler' method to fix this. > Error: URI=null Line=105: cvc-complex-type.2.2: Element 'attribute' must > have no element [children], and the value must be valid. > Error: URI=null Line=125: cvc-complex-type.2.2: Element 'attribute' must > have no element [children], and the value must be valid. > Error: URI=null Line=149: cvc-complex-type.2.2: Element 'attribute' must > have no element [children], and the value must be valid. > Error: URI=null Line=179: cvc-complex-type.2.2: Element 'attribute' must > have no element [children], and the value must be valid. > Error: URI=null Line=207: cvc-complex-type.2.2: Element 'attribute' must > have no element [children], and the value must be valid. > > so... what to do?? > > 1. ignore these messages, after all it works > 2. Try to modify the attributes-1.1 schema to allow mixed content. > Today anyway this is beyond my schema-fu. In any case mixed content is > pretty evil, we should try to avoid it if possible. > 3. Introduce an xml-attribute element in config.xml. This is going to > require bigger changes in the object model holding the values: we'll > need either a new element or a flag to tell it to write out > rather than > > (3) is probably the most plausible way to go, but I'm not enthusiastic > about cramming this into 1.1. I think (1) for 1.1 followed by more > thought and perhaps (3) for 1.2 is the way to go. > > Thoughts? > > thanks > david jencks > > > >