Hi Radu,
Came across this when I was digging through a backlog of messages and
figured it rated a reply, despite the long time since the original exchange.
On the mapping vs. generation issue, I think the best approach really
depends on your individual application requirements. Are you working
from an existing, stable, schema, with no existing codebase? Then code
generation from schema is likely to be the easiest and fastest approach.
Are you working from an existing application, with flexibility to define
the schema to suit your needs? Then mapping is likely to be the easiest
and fastest approach. Most applications fall somewhere between these
extremes, so the choice is less clear-cut.
I think most developers would disagree with you on the ease of writing
translation code in Java, vs. doing it via a configuration file. The
issues of maintaining and updating the logic are the same in either
case, and certainly many users of JiBX would disagree with your claim
that mapping is not a solution to real-world problems (see the JiBX user
comments page at http://www.jibx.org/comments.html for a few statements
on this). When you start dealing with schema versioning issues the
benefits of mapping become even stronger, since it can allow a single
data model to be used across multiple schema versions while code
generation approaches generally require a whole new data model (and
translation code) for each schema version.
I do agree with you that XMLBeans is the closest thing to a generic XML
library, and I think it's a very useful framework for that reason. The
ability to mix tree-based XPath and XQuery with a data binding facade is
useful to a wide range of applications, especially those where data from
many different types of documents needs to be processed by a single
application. XMLBeans is much weaker when it comes to pure data binding
applications, where the generic approach gets in the way and results in
larger memory footprint and processing overhead.
- Dennis
Radu Preotiuc-Pietro wrote:
Here's a couple of thoughts on this:
First, on the migration subject. Migration is a difficult issue, in this case
complicated by the fact that users depend on generated artifacts. Saying that
manual mapping of existing Java code to Schema interfaces is allowed doesn't do
much in solving it. You still have to map 100 Java classes to their Schema
counterparts and in more realistic scenarios, the number is 1000+. That's logic
that you will have to maintain and update as time goes by, and why would you
write this logic in an XML or text config file rather than writing it in Java,
when writing logic is what Java is good at. I actually have first-hand
experience with the problem of mapping existing Java classes to existing Schema
classes and in the end it may be something to make the user feel more
confortable, but not a solution to a real-world problem.
On the generic XML library, isn't XmlBeans is the best example of this? We support Java typed access, DOM, SAX, StAX, XmlCursor (it serves the same purpose as DOM, but much faster), Xpath/Xquery. We don't support everything you may think of, but what we do support is pretty well integrated. That gives the user the freedom and power to combine whatever tools are best without the penalty of having to convert between formats and lose data in the process.
Now the trouble with making it general is that the integration will not be as seamless,
since you need specific statically-bound methods to make it very usable (like a
.getJDomNode() where you currently have .getDomNode() or JDOM-typed parameters to factory
methods). To overcome that and to make the performance acceptable you would have to bake
any new model in the XmlBeans code directly. And even with "just" the models we
currently support, you get penalized on performance.
But, let's take heart from the fact that Java itself was criticized for
performance reasons at the beginning, but users loved the simplicity and power
that it offered them and eventually the performance got better and better until
here we are today ;-)
Sorry for the long post,
Radu
-----Original Message-----
From: Jean-Christophe Pazzaglia [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 26, 2005 1:31 AM
To: [email protected]
Subject: Re: Migrating from castor to XMLBeans
Hi Dennis,
Very good analysis of the strengths and weaknesses of frameworks that I
fully support,
(if you look carefully my post you'll notice an interrogation mark near
SAX)
[can I integrate it in my lectures :) ?]
However, I do believe that a library can cover the spectrum from generic document model (DOM) to specific data binding (java or xml centric). Upto a certain extent Castor was able to use both approach, however since it does not keep the original document (correct me if I am wrong) which
implied
that it was impossible to add DOM features and quite difficult to add
xpath alike accessor.
(which motivated my switch to XMLBeans)
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.
Maybe someone can imagine a way to integrate standard classes into an XMLBeans framework, this will probably imply to automatically generate a schema from the classes (should not be too difficult) and to provide on demand the XML document. Specific annotations or interfaces may enable to modify the generic binding. Ideally, the document should be tagged to keep track that, in this case, the main data representation is in java and that any modification of
the document
should be done in the object too (which may be more problematic).
The questions are :
- is it worst the job ?
- will it not be more difficult for the developer ?
- will the performance overhead be not too prohibitive ?
Sorry for the noise :)
jc
side note : how can you agree with someone who is willing to replace
reflection with compiled code :P ?
Dennis Sosnoski wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
