geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: XML POJO Update (XMLBeans)
Date Wed, 08 Oct 2003 20:25:21 GMT
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


Mime
View raw message