+1
Would rather use a tool to generate objects to reduce code maintenance, but whatever for now.
--jason
On Monday, September 1, 2003, at 03:41 AM, 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:[EMAIL PROTECTED] Sent: Sunday, August 31, 2003 11:34 AM To: [EMAIL PROTECTED] 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
