geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject [vote] XML Parsing
Date Sun, 31 Aug 2003 20:41:39 GMT
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

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
  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
  object graph as needed - for example, DConfigBean impls might subclass
  object and add support for the DConfigBean interface and change

* We define a simple, loader framework that can load an XML instance
  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
  by the underlying parser. This should be kept really simple as the
  intention is to throw it away. How this is done is not yet known -
  may be an option.

* We look for a framework that provides load and store functionality
  schema validation of data during the store process) between XML
  documents and the POJO object graph. The most likely candidate here is
  as, eventually, it should be easy to modify it to get the exact
behaviour we

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).


> -----Original Message-----
> From: Aaron Mulder [] 
> Sent: Sunday, August 31, 2003 11:34 AM
> To:
> 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

View raw message