Pretty OT, but I thought I might get some insightful answers here.
Does anyone know of a good marshalling/unmarshalling solution?
XMLBeans only works with JDK 1.4 and we need a 1.3 solution.
Sun's RI of JAXB seems kinda slow. We need something faster, if possible.
Enhydra Zeus doesn't handle our xsd correctly.

Any suggestions would be appreciated.

Thanks

Eric

Hi,

I've been using Castor XML for a few months now and it works great.

http://castor.exolab.org/

You might want to look into Jibx as well. Its supposed to be the fastest framework for binding XML data to Java objects. Its in beta right with a production version 1.0 by end of the year.

http://jibx.sourceforge.net/

slug.

Thanks. I got the Castor recommendation from somone else, as well. Working well so far. My test message now takes 20ms to unmarshall vs 80 - 90 with JAXB.

Have you tried the XMLEncoder/XMLDecoder that is part of the JDK1.4?

If you're not worried about the XML structure it might be a good choice.

The way JiBX works, with an XML mapping file and byte code enhancement, seems very similar to the way Hibernate works.

Since it seems to make sense to unify these mapping technologies (does Castor achieve this?), wouldn't it make sense to extend Hibernate in some similar way so that infrastructure could be unified for Java/SQL/XML mapping? One immediate benefit: if I could do my queries using HQL and get my results as XML without having to create intermediate Java objects...

The benefits should be obvious for architectures which leverage XSLT or web services... Is this even on the radar screen for Hibernate??

See http://jibx.sourceforge.net/index.html for more information on JiBX.

Well, I don't think that this is a core functionality of object/relational mapping, but I can see some use as an addon. It's not on any todo list though ;)

It may not be directly part of O/R mapping but it is definitely part of what real J2EE applications deal with: web services for a service oriented interface and XSLT for a clean MVC framework.

It just seems so inefficient to create artificial boundaries over what goes in a persistence framework when XML, Java, and RDBMS are such core technologies and there continues to be this "impedance mismatch" that everybody is trying to solve. Better to have a single unifying framework. Especially, whereas the mapping technology is so similar.

I'm not sure that I understand the notion that a persistence service should do persistence is an "artificial boundary".

Notice that we are talking about two different impedence mismatches here: object/relational and object/heirarchical.

And, there is no end in that logic. We might as well add a GUI validation framework, GUI component databinding and a network communication layer to Hibernate, if we want a unifying framework ;)

We should stop when it can read e-mail though...

Actually, the end goal is HibernateOS.

OK guys, I get the message.

But Gavin, surely you know that all the major RDBMS vendors deal with retrieving query results as XML. It is clearly a real world problem that they have been addressing for a while and with good results. So constraining the problem domain to object/relational prevents hibernate from getting the leverage that these vendors get when they hook up all these components under the hood.

What you're saying is that if I want the efficiency of going from a query to an XML result, I would have to resort to the native database mechanisms (they are all different) rather than having a single portability layer. What is distasteful about this is that then I am building hybrid solutions - half hibernate when I want objects and half native RDBMS when I want XML. With two different query languages.

The alternative is to build the XML persistence piece separate from hibernate. Perhaps that is the answer. Just seems like a lot of duplication of the overlapping technology. Especially if I want to use one query language.

It seems that Microsoft understands the impedance mismatch referred to above very well.

In what appears to be a deliberate leak, a research paper on a new Microsoft language called Xen was published:
http://www.cl.cam.ac.uk/~gmb/Papers/vanilla-xml2003.htm

Xen addresses the impedance mismatch by creating a language that unifies access to XML and SQL data. This looks like exciting stuff and directly addresses the issues raised earlier in this thread.

Microsoft also invented a user interface called "Bob". ;)

Sorry, corrected URL:
http://www.cl.cam.ac.uk/~gmb/Papers/van ... l2003.html

And they also have over 50B in the bank...

Christian, just let your forum readers decide for themselves instead of trying to influence them.