Discussions

News: Article: Using JaxMe, an open source JAXB implementation

  1. Brett McLaughlin has written a nice in-depth look at JaxMe, an open source implementation of JAXB. In addition to offering several enhancements to the basic JAXB specification, JaxMe offers integration with databases and Enterprise JavaBeans, both significant extensions to basic data binding behavior.

    Introduction
    It's no secret that Sun's JAXB, the Java API for XML, has had its fair share of criticism. In its earliest iteration (beta something-or-other), it was based on DTDs, and didn't support W3C XML Schema at all. It sat in that state for over a year, and then suddenly a 1.0 version was released. While that version addressed the schema support, it dropped DTDs completely, and all the code that developers had written (admittedly to beta software) suddenly stopped working. In more recent days, JAXB has picked up some support, but it still remains a very closed environment, with plenty of bugginess in the darker corners of the implementation.

    In this article, I'll introduce the JaxMe project, which keeps most of JAXB's good features, and dumps many of its problems. First and foremost, though, JaxMe is open source (and under the Apache umbrella), which means that even if it disappeared today, developers could freely use and even modify its source code -- ensuring that code depending on it will happily go on running. If this alone isn't enough, JaxMe offers database interaction, support for Enterprise JavaBeans, and all sorts of other goodies.
    Read: JaxMe - The new kid on the block
  2. Why am I the only one who thinks these XML binding people are getting it backwards? Everything I've seen, from initial JAXB implementations, to this, to XMLBeans, is all driven by the XML.

    To me, it should be the other way around. I have a Java class I've written, or a set of legacy classes. I want to create XML from them. I want to potentially create an XML schema from them. Everything I do in my code is in Java, but I need the xml in order to communicate with outside parties, or to handle serialization. Why don't these tools let the Java drive the XML? Most of us here are Java programmers, not Xml writers. So why is everything I see based upon the XML first? It seems to me that it's far more common a requirement to generate XML given a set of classes than it would be to generate classes from an XML document or schema.

    Am I crazy, or just missing something? I have a lot of cases where I need to do this, and I need to have fine-grained control over the XML output. I can't think of anything readily available that will help me do this (starting with Java first, not XML first). At least not in the Java world. The .NET xml serialization seems to be a little less "XML first".
  3. Although only in early draft form, take a look at the JAXB2 specification. Chapter 8 (Java to XML) defines a metadata set for fine grained mapping of pre-existing Java classes to XML schema elements.

    There are some interesting possibilities here with respect to domain objects. With JAXB2 and EJB3, you can annotate an object to handle persistence, detachment through to the presentation layer and then serialization to XML for presentation. It will be interesting to see how this evolves.
  4. Drew,

    While I cannot speak to your relative sanity or lack thereof, I do agree that going from the XML to the class is the wrong approach.

    I wrote a tiny library that loads and stores XML into objects. It was kind of neat. The root tag was <kluge>, then had <object> nodes with a name that was the package and class names for the Java object. I then used reflection to marshall or unmarshall my XML. It took me about 30 minutes to write and it's been pretty useful.
  5. You have to ask yourself why you are using xml in a first place. It might help to read David Bau's blog (http://davidbau.com/archives/2003/11/10/xml_best_practices.html)
  6. Believe me, I agree wholeheartedly that the question of why xml in the first place is the most important question. Too often, I see people using or recommending XML as some sort of default serialization technique when it's completely unnecessary. My favorite example is serialization of object to XML for web page display using XSLT. That's just way too many steps for something that JSPs or Velocity can do using an object directly, without XSLT transforms, without any unnecessary serialization, and with a result that is usually a lot more human readable.

    That said, there are a lot of cases where it is useful to be able to quickly and easily map java objects to XML in a controlled way. For example, you have an object that can be saved to a filesystem instead of a database, and you want to define the file format. Or you have a config object tree for configuring some system and you want to define your config file format. In both cases, you want control over how the file looks to enhance readability. Also, being able to generate a schema based on the object tree is helpful because it then becomes easy to validate the file before reading it in, so you don't have to deal with tracking down bad file formats.

    .NET has some xml serialization classes that work mostly using attributes (the .NET equivalent of Tiger's annotations). But it also provides a way to use the serialization without marking up your classes (perfect for when you don't want xml dependencies, or you're working with classes you can't control). I've built a thin wrapper around this that makes it really easy to use:

    XmlToTypeMapping mapping = new XmlToTypeMapping(typeof(MyClass), "myClass");
    mapping.AddAttributeMapping("prop1", "Prop1", typeof(string));
    mapping.AddAttributeMapping("prop2", "Prop2", typeof(int));
    mapping.AddElementMapping("childProp", "ChildProp", typeof(MyClass));

    XmlToTypeSerializer s = new XmlToTypeSerializer(mapping);
    s.Serialize(GetInstanceOfMyClass(), "some-file.xml");

    I would love to be able to do the equivalent in Java. The mapping is bidirectional, and after hacking in the decompiled .NET framework classes, i found out how you can use undocumented methods to use the mapping to output an XML schema.
  7. Take a look to JiBX, its intented exactly to map java objects to xml documents in a very flexible way, and made thinking on performance so is too fast. The map is made with an XML file and is powerful enough to XML-serialize almost any already existing java class.
  8. "My favorite example is serialization of object to XML for web page display using XSLT. That's just way too many steps for something that JSPs or Velocity can do using an object directly, without XSLT transforms, without any unnecessary serialization, and with a result that is usually a lot more human readable."

    You may be correct and wrong as well. It depends on your situation, if you just have a single object source then JSP can be the right choice. But, in my case, XML is the common denominator for all sources which I have to render as an Web interface. For instance, serialized java objects, SQL result sets and XML payloads are perfect for XSLT. Thus, XSLT allows me to aggregate all these sources into a single unified view. Just too imagine using JSP would create many ugly steps.

    My point, why is everyone making blanket statements for technology solutions. JSP, Velocity, XSLT or whatever are all available for developers to choose the most appropriate solution. Wow, imagine that, discussions of available techniques and "appropriate" practices - rather than, "never do this" or "always use that".
  9. Agreed, if your source is XML, then XSLT or something like Cocoon is fine. But I've seen too many examples of people going out of their way to make their source XML when it doesn't need to be. People turning Java objects into XML so they can use XSLT just because it's cool or they know XSLT or something. That's what I was railing against, I suppose.
  10. "People turning Java objects into XML so they can use XSLT just because it's cool"

    Right, this is the classic "resume driven" solution. Its unbelievable how so many people are jumping on the XML bandwagon for no reason at all. I've seen developers turn result sets into XML just to get experience with DOM and JAX. Also, seen developers use XML for their "proprietary" interfaces, only to be used by themselves.

    The problem, too many non-technical technical managers asking for XML "experience" for job candidates.

    Gee, I wonder if my XML experience would help my SOA career?
  11. If you want to do that, look at java.beans.XMLEncoder.

    XML Binding is about using XML that you probably can't control, and making it easy to transform into objects.

    So, no, it's not arse-backwards; it's a different use case.
  12. The way I see it, XML binding can just as easily be about Java code you can't control as XML you can't control. The binding should be two-way, in my opinion. That's the way the .NET serialization works. The different use case is just doing the same thing in the other direction. And I would argue that the other direction, in this case, going from Java to XML, is probably a more frequent use case. At least it has been in the potential uses I've seen in projects over the past few years.
  13. Different kind of use case[ Go to top ]

    Why am I the only one who thinks these XML binding people are getting it backwards? Everything I've seen, from initial JAXB implementations, to this, to XMLBeans, is all driven by the XML.To me, it should be the other way around. I have a Java class I've written, or a set of legacy classes. I want to create XML from them. I want to potentially create an XML schema from them. Everything I do in my code is in Java, but I need the xml in order to communicate with outside parties, or to handle serialization. Why don't these tools let the Java drive the XML? Most of us here are Java programmers, not Xml writers. So why is everything I see based upon the XML first? It seems to me that it's far more common a requirement to generate XML given a set of classes than it would be to generate classes from an XML document or schema. Am I crazy, or just missing something? I have a lot of cases where I need to do this, and I need to have fine-grained control over the XML output. I can't think of anything readily available that will help me do this (starting with Java first, not XML first). At least not in the Java world. The .NET xml serialization seems to be a little less "XML first".
    for internal application integration i would agree completely a java centric approach is probably better. Have you looked at XStream and Jibx? JAXB is a valid approach when you're integrating applications from third parties, which you can't control and have no way of controlling. In those cases, you just want a way to be able to map and load the data into the desired internal object model. Once the data is loaded, you do your business, then send the result back to the third party is their preferred format.
  14. Skaringa??[ Go to top ]

    Perhaps I don't understand exactly what kind of tool you are looking for, but it would seem Skaringa http://skaringa.sourceforge.net/ might be what you are looking for.
  15. You are missing some points[ Go to top ]

    Why am I the only one who thinks these XML binding people are getting it backwards? I have a Java class I've written, or a set of legacy classes. I want to create XML from them. It seems to me that it's far more common a requirement to generate XML given a set of classes than it would be to generate classes from an XML document or schema. Am I crazy, or just missing something?
    There are circumstances in which your viewpoint is appropriate, but yes, you are missing somethings.

    Consider the cases in which multiple companies' products are combined to produce a solution that is expected to have a long (years/decades) lifetime. Those companies probably don't even know that each other exist, their products have separate lifecycles and upgrade intervals, their products are written in different languages, and the overall solution will be gradually extended over time.

    In those cases an implementation neutral, stable, well defined API is valuable as a key integration point. Think IDLs, in which case XMLSchema isn't a bad starting point.

    And it is natural to go from the IDL to the POJO/servlet/EJB/.NET/Spring/etc, not the other way around.
  16. Why am I the only one who thinks these XML binding people are getting it backwards? Everything I've seen, from initial JAXB implementations, to this, to XMLBeans, is all driven by the XML.To me, it should be the other way around...
    I appreciate someone else has already stated this, but JiBX (http://jibx.sourceforge.net/) provides a clean way for binding XML data to Java objects without the structure of your XML forcing structure on your classes and vice versa. This is achieved through binding definition documents, which describe how objects can be transformed into XML. So long as there is a sensible way by which to define a mapping, your XML and class structures do not have to be identical. I've only used an early version of JiBX on a small project but it proved itself to be very powerful.

    In addition, on another project we're currently using JAXB. We have found it necessary to define lots of converter classes comprising static to/from JAXB methods in order to transform our XML schema-driven Java object representation into domain objects. If we had chosen to use JiBX instead, our mappings would exist in a versatile binding definition rather than in all those static 'adapter' methods resulting in a cleaner, more compact codebase.

    James.
  17. XML Data Binding resources[ Go to top ]

    http://www.rpbourret.com/xml/XMLDataBinding.htm