From geronimo-dev-return-2937-apmail-incubator-geronimo-dev-archive=incubator.apache.org@incubator.apache.org Tue Sep 02 11:39:01 2003 Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 57414 invoked from network); 2 Sep 2003 11:39:01 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Sep 2003 11:39:01 -0000 Received: (qmail 77961 invoked by uid 500); 2 Sep 2003 11:38:47 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 77915 invoked by uid 500); 2 Sep 2003 11:38:47 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 77891 invoked from network); 2 Sep 2003 11:38:46 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 2 Sep 2003 11:38:46 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19u9HJ-0000Ql-00 for ; Tue, 02 Sep 2003 13:24:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: geronimo-dev@incubator.apache.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19u9HI-0000Qd-00 for ; Tue, 02 Sep 2003 13:24:52 +0200 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 19u9Gj-0007QU-00 for ; Tue, 02 Sep 2003 13:24:17 +0200 From: Greg Wilkins Subject: Re: [vote] XML Parsing Date: Tue, 02 Sep 2003 21:22:37 +1000 Lines: 182 Message-ID: References: <001c01c37000$47c416d0$b625a8c0@ABU> <3DE10E7A-DC7C-11D7-8FD9-000A959D0312@yahoo.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030827 Debian/1.4-3 X-Accept-Language: en In-Reply-To: <3DE10E7A-DC7C-11D7-8FD9-000A959D0312@yahoo.co.uk> Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N +1 for james amendment (ie use a naming convention that gives us mashalling for free - but no opinion on betwixt vs digester etc.) +1 for pojos (well for doing something). I'm happy to write/generate the classes for the webapp deployment descriptor - but there is now a twisty little maze of schema dependancies on the j2ee descriptors. James Strachan wrote: > +1 > > with a minor change. If we're gonna be hand-coding POJOs ourselves then > there's less reason to use XMLBeans - so I suggest we use something like > betwixt rather than XMLBeans to do the parsing / converting to XML. > Thats probably gonna be easier to use and have a smaller dependencies in > terms of jars. Then we just need to follow some simple naming > conventions in the POJOs to get the XML marshalling for free. e.g. > > public class WebApp { > > public void addServlet() { > ... > } > > public List getServlets() { > ... > } > > } > > public class Servlet { > public String getName() {..} > public void setName(String name) {...} > } > > > > > On Sunday, August 31, 2003, at 09:41 pm, Jeremy Boynes wrote: > >> At this time I think the biggest issue is the lack of decision. None of >> the solutions seems, at this time, to be complete let alone perfect. >> XMLBeans appears to offer the most complete solution long term but does >> not seem to be ready now. Castor looks like a partial, short-term >> solution, but may not work long-term and may have licensing issues >> (Intalio). >> >> I suggest the following plan: >> >> * We define POJOs that represent the data objects but which are not >> bound to XML >> or to any usage model (e.g. DConfig). This provides us with an object >> model >> for the data everyone can use no matter which framework we end up >> using. A >> requirement for the framework is that it can populate the data into >> and out >> specializations of this object graph. >> >> * Each tool that needs this data model can specialize the behaviour of >> this >> object graph as needed - for example, DConfigBean impls might subclass >> these >> object and add support for the DConfigBean interface and change >> notifications. >> >> * We define a simple, loader framework that can load an XML instance >> document >> into this object graph. This is load only, so does not need to deal >> with any >> modifications to the graph. It does no validation over and above that >> supplied >> by the underlying parser. This should be kept really simple as the >> ultimate >> intention is to throw it away. How this is done is not yet known - >> digester >> may be an option. >> >> * We look for a framework that provides load and store functionality >> (including >> schema validation of data during the store process) between XML >> instance >> documents and the POJO object graph. The most likely candidate here is >> XMLBeans >> as, eventually, it should be easy to modify it to get the exact >> behaviour we >> need. >> >> I would ask for a vote on this an an approach - please limit responses >> to +1, 0 or -1 and why (we have had enough discussion of alternatives >> for now). >> >> -- >> Jeremy >> >>> -----Original Message----- >>> From: Aaron Mulder >>> [mailto:ammulder@alumni.princeton.edu] >>> Sent: Sunday, August 31, 2003 11:34 AM >>> To: geronimo-dev@incubator.apache.org >>> Subject: [XML Parsing] >>> >>> >>> On Sun, 31 Aug 2003, Jeremy Boynes wrote: >>> >>>> ... >>>> Where are we on XML parsing? >>> >>> >>> I'd like to resolve that too. I've worked a bit with >>> both Castor >>> and XMLBeans on the deployment stuff, and here's what I've >>> come up with: >>> >>> - Castor produces plain Java objects, with another layer of XML info >>> objects that can be essentially ignored at runtime (they're used only >>> under the covers) >>> >>> - XMLBeans produces richer objects, which know the name of >>> the document they came from, support XPath queries, and so >>> on, but also have a lot more in them than seems strictly >>> necessary, and code is generated in at least one cryptic >>> package other than the one(s) you're targeting. >>> >>> - Castor appears to depend on overriding the Xerces version >>> in the JDK >>> (for 1.4.2) >>> >>> - I can't get XMLBeans to actually load a document right now >>> (due to some >>> kind of missing file dependency?) >>> >>> - Castor has a smaller runtime library (over 1MB, but about >>> 1/2 the size >>> of XMLBeans) >>> >>> - XMLBeans is in the process of moving from BEA to Apache, >>> but at last >>> notice the source wasn't imported and the build script wasn't >>> working. On >>> the other hand the current download from BEA appears to be >>> covered by a >>> BSD license. >>> >>> - reportedly Castor won't generate object for the full J2EE >>> schema, while >>> XMLBeans will, and JAXB will (painfully) [from James] >>> >>> - I know nothing else about JAXB >>> >>> - Castor is currently integrated into the build scripts (for >>> Twiddle and the Geronimo EJB DD schema), while XMLBeans isn't >>> quite (the code is there but the scripts need to be tweaked a bit) >>> >>> I hope James will speak up, because I think he has more >>> experience with JAXB and XMLBeans and the J2EE schema issue. >>> I have a slight preference for Castor (since it and the beans >>> it generates are both lighter weight), but I'm willing to go >>> with XMLBeans if we can resolve the problem reading XML into >>> objects and it's the only way to get the J2EE schema out (and >>> the XPath feature seems likely to be pretty handy too). >>> >>> Bottom line, I'd like to be able to just make a >>> decision and move >>> forward. >>> >>> Aaron >>> >>> >> >> > > James > ------- > http://radio.weblogs.com/0112098/ > >