geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [vote] XML Parsing
Date Mon, 01 Sep 2003 13:00:20 GMT

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. 

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 []
>> 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