geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: [vote] XML Parsing
Date Tue, 02 Sep 2003 18:41:13 GMT
+1 on POJOs

<sharing-of-experience-not-a-proposal>
OpenEJB took this route and it's paid us back a few times.  We started out with one big xml
file as our config file.  It proved to be just a really bad schema for users and we created
a new config concept that consisted of an xml/properties file mix which was much easier for
users to manipulate without a tool.  

Because all our system was written against the POJOs, we didn't have to change any code (just
write more) and are able to support the old style as well as the new style of config files.
 

Here's documentation on the old style (as you can see, Apple is still using it)
  http://developer.apple.com/documentation/WebObjects/Enterprise_JavaBeans/ConfigurationReference/chapter_7_section_4.html

Here's documentation on the new approach
  http://www.openejb.org/config_containers.html

If you just take a quick glance at them you'll see they are totally different.  You'd never
get that flexibility without the POJO concept.

Here is how we designed it (for reference):
  http://www.openejb.org/design_configfactory.html

</sharing-of-experience-not-a-proposal>

-David


On Sun, Aug 31, 2003 at 01:41:39PM -0700, 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
> > 
> > 

Mime
View raw message