Hi jc,
This seems a lot like saying "it's really annoying to have to use cars,
boats, and planes to get places - why don't people just build a single
device that replaces all of these?" :-)
There are a lot of overlaps between the different frameworks for working
with XML in Java, but also a lot of differences. At the parser level,
SAX and StAX are fundamentally different. The document model differences
are more cosmetic - DOM, JDOM, dom4j, XOM, etc. are all basically just
variations of a tree API. When you get to data binding, the differences
are again very real.
I see mapped binding approachs as being fundamentally Java-centric,
where you add the XML data binding in an aspect-oriented fashion to your
existing Java classes. Castor used this approach originally, and still
supports it, but JiBX offers greater flexibility (as well as much better
performance than Castor). JAXB 2.0 also offers limited support for
mapped bindings, using annotations in code.
The other type of approach is code generation from schema, which is
inherently schema-centric. Most data binding frameworks support this
approach, though with different limitations on the schema constructs
supported.
XMLBeans really crosses the framework classes, in that it combines a
document model with data binding (perhaps more accurately, it builds a
data binding facade on a document model architecture). This gives it
unique strengths, especially for developers who need to access the full
structure of the XML but also want to access typed data values through
Java objects. It also makes for some weaknesses - XMLBeans generally
uses a lot more memory than conventional data binding frameworks, and
operates considerably slower (especially when reading or writing data
through the data bound objects). AFAIK, it also requires developers to
use classes generated from schema for the data binding operation, making
it one of the few data binding frameworks that offers no support
whatsoever for working with ordinary Java classes.
- Dennis
Jean-Christophe Pazzaglia wrote:
Hi,
I am involved on XML Programming since 98
and back in 99 (my first lecture on the topic)
I was already wondering why someone was not
able to provide a common framework to 'program' XML.
6 years later it seems that we still have to use different
libraries for different needs, I moved to XMLBeans from
Castor because I thought that XMLBean was more promising
(notably the integration with xpath and that it keeps the original document,
while probably Castor is better as doing customized and schemaless mapping)
and I am still fighting integrating code using DOM with my XMLBean
library, so I am simply wondering :
is it not possible to have one framework (let's say XMLBean++) able
to provide the solution (e.g integrating JAX*) , providing handy switch
between the different programming model (so I can use it as a
SAX(?)/DOM/JDOM
provider and switch idiom when needed [I know it may not be so simple ...])
jc
from
Your best choice is probably JiBX (http://www.jibx.org). JiBX is the
fastest XML data binding framework (https://bindmark.dev.java.net/),
and lets you work with existing classes. You can use the binding
generator from the tools subproject to generate a default binding from
your existing classes, then customize that if necessary to get exactly
what you want.
If you have questions about JiBX, join up on the JiBX users mailing
list (http://sourceforge.net/mail/?group_id=69358) and send the
questions there.
- Dennis
Zhong ZHENG wrote:
Hi,
Thanks for your advice. But the format of my XML file is already
defined, although i did not create schemas. If necessary, i may
create schema for my XML. But i do not want to use XMLBeans-generated
classes. So is it possible to do the data binding by using my own
java beans?
Regards.
On 10/22/05, *Giedrius Trumpickas* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
If you don't have schemas defined for your XML and have already
existing beans use:
http://xstream.codehaus.org/
Giedrius
--
ZHENG Zhong
1 Avenue Alphand
75116 Paris, France
+33 6 76 80 45 90
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
