Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 77842 invoked from network); 8 Oct 2003 20:22:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 8 Oct 2003 20:22:58 -0000 Received: (qmail 67089 invoked by uid 500); 8 Oct 2003 20:22:38 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 67035 invoked by uid 500); 8 Oct 2003 20:22:38 -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 67022 invoked from network); 8 Oct 2003 20:22:38 -0000 Received: from unknown (HELO www.princetongames.org) (66.250.40.202) by daedalus.apache.org with SMTP; 8 Oct 2003 20:22:38 -0000 Received: from localhost (ammulder@localhost) by www.princetongames.org (8.11.6/8.11.6) with ESMTP id h98KPLx21222 for ; Wed, 8 Oct 2003 16:25:21 -0400 X-Authentication-Warning: www.princetongames.org: ammulder owned process doing -bs Date: Wed, 8 Oct 2003 16:25:21 -0400 (EDT) From: Aaron Mulder X-X-Sender: ammulder@www.princetongames.org To: geronimo-dev@incubator.apache.org Subject: Re: XML POJO Update (XMLBeans) In-Reply-To: <3F8468E4.8050209@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 8 Oct 2003, Jacek Laskowski wrote: > Does it mean that we're considering it as a tool to handle our XML files > ? I thought we'd agreed that the files were to be parsed by our own > code. Would it be changed in the future? When? I doubt if we keep > writing the code ourselves nobody will ever want to rewrite them to use > the tool. I think that many people (myself included) would like to be using a tool rather than writing things ourselves. As of the last time this was considered, none of the tools really did the job, so we decided to do it ourselves in the short term. For my 2 cents, I don't want to use a tool unless we can configure the output to be fairly similar to what we can/did code by hand. That's one of the issues I'm still working through. The main advantage of a tool is that though the hand-coded POJOs are pretty nice and user-friendly, it is fairly painful to write all the code necessary to both read and write each of the 12+ files we're talking about here (that's DDs only, not the Twiddle or kernel config files). Right now I think we have code to read 7 of the 12 and write 2 of the 12 files, and that's after a fairly significant effort. As well, the hand written POJOs will be difficult to keep accurate and up to date as the schemas change (right now the Geronimo extensions are pretty minimal, but the volume of DD elements for all the other app server suggests that there will be significant growth here). > What about picking up one (e.g. XMLBeans) and dealing with its pros and > cons or just create a service that does the job for us, i.e. reads the > DDs (or any other XMLs) and provides POJOs? I don't have any idea how > long it would take, but it's worth at least to talk about it (again). I have the highest hopes for XMLBeans out of all of the options, which is why I am pursuing it now. But I'm still not totally convinced that it can be made to work the way we want. As far as a service goes, this is really a development-time tool. We're going to be compiling code against the beans, so we can't have them generated on the fly at runtime or something. That being the case, a layer of abstraction over the selected bean generator doesn't seem all that useful to me... Aaron