geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: [vote] XML Parsing
Date Tue, 02 Sep 2003 11:22:37 GMT

+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/
> 
> 



Mime
View raw message