Discussions

News: Xmappr released

Bookmark and Share Get thread feed

  1. Xmappr released (26 messages)

    • Posted by: Peter Knego
    • Posted on: December 31 2009 08:19 EST
    Xmappr is a lightweight library for mapping XML to Java, with some unique features that make it worth checking out. * Simple configuration. Object-to-XML mappings are configured via Java annotations or external XML configuration. * Partial mapping. Map only a part of XML document that you are interested in. Unmapped XML will be preserved on output. * XML namespaces are fully supported. * Preserves order of XML elements from input to output. * XML element and text mixing supported. Can map XHTML. * Extensible. Custom converters can be written to support custom type conversions. * Lightweight. Only 80kb in size with no dependencies. * Thread-safe. Designed for multi-thread use. * Permissive license: released under BSD license. Give it a try. Download here.
    Reply to this

    Threaded Messages (26)

  2. Re: Xmappr released[ Go to top ]

    Does it support XSD XML Schema ? I couldn't find references to it in the documentation.
    Reply to this Reply to original

  3. Re: Xmappr released[ Go to top ]

    Does it support XSD XML Schema ?

    I couldn't find references to it in the documentation.
    The main focus of Xmappr is not XML validation. As such it does not support XML schemas.
    Reply to this Reply to original

  4. What about JAXB annotations?[ Go to top ]

    It sounds like a bad decision not to support the JAXB annotations. Why is that?
    Reply to this Reply to original

  5. Re: What about JAXB annotations?[ Go to top ]

    It sounds like a bad decision not to support the JAXB annotations. Why is that?
    Being a JAXB implementation is not one of the goals of Xmappr, but rather it tries to be simple, fast and flexible. However, if you believe that Xmappr lacks a feature that you might need to use it, we are ready to listen. Just drop a note on the mailing list. Peter
    Reply to this Reply to original

  6. Looks very interesting[ Go to top ]

    I've been looking for something like this. I currently use XStream, and really like it, but its annotations are limited and customizing the XML output seems to always lead to custom converters, in which case I might as well write it by hand to begin with. Your solution is interesting to me because of the annotation based approach to customizing the serialization. I'm not too interested in the XML config, as writing XML to configure XML has always annoyed me. :-) One thing I noticed in the docs is that you require this to look up the type of the collection: @Element(targetType=Integer.class) List number; It is possible in Java to get the generic type. Type erasure only applies to instances, you can get the type argument information from the class definition. It's understandable that you might not have noticed this, as it's quite possibly one of the worst and deepest hidden APIs in the JDK... Here it is (hope the formatting holds): public class Foo { // example code... lacks a lot of error checking here private List integers; public static void main(String[] args) { final Field[] declaredFields = Foo.class.getDeclaredFields(); final Field firstField = declaredFields[0]; // obviously unsafe final Type genericType = firstField.getGenericType(); final ParameterizedType parameterizedType = (ParameterizedType) genericType; // * here's the trick final Type[] typeArguments = parameterizedType.getActualTypeArguments(); final Type firstTypeArg = typeArguments[0]; // obviously unsafe System.out.println(firstTypeArg); } } I (for one) am happy that you aren't using JAXB annotations or worrying about standards. I want best of breed, not standard. You might have something here, so keep going. Best regards, Clinton
    Reply to this Reply to original

  7. Re: Looks very interesting[ Go to top ]

    @Clinton - thanks for the tip on parametrized types. I was so under the influence of all the talk about type erasure that I did not even consider looking for such information. It seems that type erasure is the biggest misconception in Java history. I'm already investigating how to use this in Xmappr. Thanks again, Peter
    Reply to this Reply to original

  8. Re: Looks very interesting[ Go to top ]

    As a member of the JAXB expert group (JSR-222), and the object-to-XML component (MOXy) lead of the open source EclipseLink project (http://www.eclipse.org/eclipselink/), let me share what I feel are some of the advantages of the JAXB standard: 1. Input from many parties including representatives from Sun, Oracle, IBM, BEA, SAP, etc. 2. Compatibility with other standards such as JAX-WS. JAXB is the JAX-WS binding layer. 3. Ability to easily switch between JAXB implementations. All you need to do is add a jaxb.properties file to take advantage of a different implementation. This prevents being locked into a particular implementation. 4. A large user base. JAXB has been included in the JDK since Java SE 6, and been used by every developer creating JAX-WS Web Services. 5. Using a JAXB 2.X implementation guarantees that 100% of the XML schema concepts are covered. 6. An easily extendible runtime. EclipseLink provides: XPath based mapping, extensions for mapping JPA entities (such as composite keys, embedded key classes, and bi-directional relationships), etc. -Blaise
    Reply to this Reply to original

  9. Re: Looks very interesting[ Go to top ]

    Like most of the OSS projects, Xmappr started because I had an itch to scratch. The task was to read a docx documents (huge ones), read/change some data and write it back out. I tried to do this with various libraries but could not get it done. Most of them forced me to map the whole of the xml document, which was an overkill, because we needed to read/change just a particular part of it. I had most success with Xstream, which had to be patched to be able to do this: http://jira.codehaus.org/browse/XSTR-474 But at the end even this did not cut it, so I set out to write something from scratch. Also, on most projects I worked, nobody really cared about XML schemas. They just presented an example XML an we had to work from that. Just my 2c. Peter
    Reply to this Reply to original

  10. Re: Looks very interesting[ Go to top ]

    I understand your interest in object-to-XML mapping. I've been developing object-to-XML support in TopLink/EclipseLink for over 7 years and still get excited about adding new features. When dealing with a sub-tree, JAXB and TopLink/EclipseLink users simply map the portion of the XML document they are interested in, and then pass the local root to the unmarshal operation. This local root can easily be obtained using the javax.xml.xpath APIs (included in Java SE 5). As for XML schemas, neither JAXB or TopLink/EclipseLink require them. You can simply start with Java classes and convert instances of them to XML. No annotations are required, but many are available to customize the format of the resulting XML. Of course XML Schemas can be used to generate Java classes, or used in the TopLink/EclipseLink Workbench to facilitate meet-in-the-middle mapping. One of TopLink/EclipseLink's key differentiators is the use of XPath in our mappings. This allows you to break the one-to-one correspondence between objects and nesting of elements found in other object-to-XML offerings. EclipseLink enables the mapping of the following objects: - Customer(name: String, address: Address) - Address(street: String) to the following XML: Jane Doe 123 Any Street EclipseLink is a very user driven project, if you have any questions or are interested in contributing please contact eclipselink-users at eclipse dot org. For more information: - Main Page (http://www.eclipse.org/eclipselink/) - Wiki (http://wiki.eclipse.org/EclipseLink) - Examples (http://wiki.eclipse.org/EclipseLink/Examples/MOXy) -Blaise
    Reply to this Reply to original

  11. Re: Looks very interesting[ Go to top ]

    Hi Blaise, thanks for all the info. I was actually trying to map the example classes and xml you provided. But after about 20 minutes of browsing through EclipseLink docs I was still lost. Peter
    Reply to this Reply to original

  12. Re: Looks very interesting[ Go to top ]

    Admittedly our user documentation could use some improvement. The good news here is that since we implement the JAXB spec, any JAXB documentation is applicable. Below is one way you could achieve the mappings I described using EclipseLink: For the Customer class we specify an XML Customizer to apply EclipseLink extensions: import javax.xml.bind.annotation.XmlRootElement; import javax.xml.bind.annotation.XmlType; import org.eclipse.persistence.oxm.annotations.XmlCustomizer; @XmlRootElement @XmlType(propOrder={"name", "address"}) @XmlCustomizer(CustomerCustomizer.class) public class Customer { private String name; private Address address; public String getName() { return name; } public void setName(String name) { this.name = name; } public Address getAddress() { return address; } public void setAddress(Address address) { this.address = address; } } For the Address class we will use all the default JAXB mapping rules: public class Address { private String street; public String getStreet() { return street; } public void setStreet(String street) { this.street = street; } } The XMLCustomizer is used to modify the object-to-XML metadata. import org.eclipse.persistence.config.DescriptorCustomizer; import org.eclipse.persistence.descriptors.ClassDescriptor; import org.eclipse.persistence.oxm.mappings.XMLCompositeObjectMapping; import org.eclipse.persistence.oxm.mappings.XMLDirectMapping; public class CustomerCustomizer implements DescriptorCustomizer { public void customize(ClassDescriptor descriptor) throws Exception { XMLDirectMapping nameMapping = (XMLDirectMapping) descriptor.getMappingForAttributeName("name"); nameMapping.setXPath("personal-info/name/text()"); XMLCompositeObjectMapping addressMapping = (XMLCompositeObjectMapping) descriptor.getMappingForAttributeName("address"); addressMapping.setXPath("contact-info/address"); } } You need to ensure that you add a jaxb.properties file in with your model classes to indicate that the EclipseLink JAXB runtime should be used: javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory The following code demonstrates how to use the runtime: import javax.xml.bind.JAXBContext; import javax.xml.bind.Marshaller; public class Demo { public static void main(String[] args) throws Exception { JAXBContext jaxbContext = JAXBContext.newInstance(Customer.class); Customer customer = new Customer(); customer.setName("Jane Doe"); Address address = new Address(); address.setStreet("123 Any Street"); customer.setAddress(address); Marshaller marshaller = jaxbContext.createMarshaller(); marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true); marshaller.marshal(customer, System.out); } } -Blaise
    Reply to this Reply to original

  13. Re: Looks very interesting[ Go to top ]

    I forgot to setup the namespace declaration. This can be done with a package level JAXB annotation, see below: @XmlSchema(namespace="urn:example", elementFormDefault=XmlNsForm.QUALIFIED) package your.model.package; import javax.xml.bind.annotation.XmlNsForm; import javax.xml.bind.annotation.XmlSchema; -Blaise
    Reply to this Reply to original

  14. Re: Looks very interesting[ Go to top ]

    I think that fact that the eclipselink project is so mature and advanced users can't get it to work easily is very telling. Its great to support standards/do all sorts of stuff, but there is a real cost to struggling with technologies. I consider a project that is mature and 'just works' to be real success, and, for better or worse, the documentation is part of that. btw - I like xstream because it does what it advertises and is fairly simple to get up and running with, which I can't say for a lot of projects. If this new product does likewise, thats great, and I personally wish it all the success in the world!
    Reply to this Reply to original

  15. Re: Looks very interesting[ Go to top ]

    To be fair, JAXB is a well documented technology that covers 100% of XML schema concepts. Anyone familiar with JAXB can use EclipseLink MOXy without reading a single page of documentation. This is the advantage of a specification, there is a standard way to do common things (why invent another annotation to map to an XML attribute?). Extensions are handled in an implementation specific way. In future versions of the spec the most useful extensions will be standardized. The example I gave was an extension, and the documentation will be improved to make this use case clearer. I wish Peter and the Xmappr project well, but also ask that developers consider contibuting enhancements to existing open source projects (or better yet join these projects).
    Reply to this Reply to original

  16. Re: Looks very interesting[ Go to top ]

    4. A large user base. JAXB has been included in the JDK since Java SE 6, and been used by every developer creating JAX-WS Web Services.
    It could be the case that this is a con for JAXB. JAX-WS generates some really awful code. The first time I ran findbugs against some recent JAX-WS generated code, dumped tons of really scary warnings about things such as incorrect synchronization. I don't know how much of this is JAXB but I would like to eliminate JAX-WS from anything I must support.
    5. Using a JAXB 2.X implementation guarantees that 100% of the XML schema concepts are covered.
    There's nothing wrong with that per-se but the problem is that too many people think schema is enough. W3C schema is a really coarse tool. There is much more to XML than what can be defined in w3c schema. RELAX NG is significantly better but nobody seems to care to support it.
    6. An easily extendible runtime. EclipseLink provides: XPath based mapping, extensions for mapping JPA entities (such as composite keys, embedded key classes, and bi-directional relationships), etc.
    When I look at the docs, all I see is stuff about generating code which, to me, is mainly a waste of time as it accomplishes almost nothing. I found a link about 'meet in the middle' mappings but it seems to be broken.
    Reply to this Reply to original

  17. Listening to users: new release 0.9.2[ Go to top ]

    Thanks to comments from Clinton Begin we just released an improved Xmappr. Xmappr now automatically infers type parameter from fields of Collection type: previously: @Element(targetType=Integer.class) public List list; can now be simplified to @Element public List list; 'targetType' attribute is now optional on Collection fields and can still be used to force Xmappr to use a certain type. New relese version is 0.9.2 Peter
    Reply to this Reply to original

  18. Re: Xmappr released[ Go to top ]

    I did a cursory look over the docs. I was wondering if you can map between a class and a document when the structures are not equivalent kind of like what can be done fairly easily in JiBX.
    Reply to this Reply to original

  19. Re: Xmappr released[ Go to top ]

    Not at the moment, but this is planned for the 1.0 release: http://code.google.com/p/xmappr/issues/detail?id=11
    Reply to this Reply to original

  20. Re: Xmappr released[ Go to top ]

    Not at the moment, but this is planned for the 1.0 release:

    http://code.google.com/p/xmappr/issues/detail?id=11
    I've thought about this a lot over the last 5 or 6 years. If you are interested, I can try to contribute some ideas. I'd offer to help code but I know I won't have time.
    Reply to this Reply to original

  21. Re: Xmappr released[ Go to top ]

    Yes please. Use mailing list for any ideas/comments/requests/etc.. Peter
    Reply to this Reply to original

  22. re-inventing the wheel[ Go to top ]

    Why are you re-inventing the wheel? JAXB is very easy to use. Either annotate existing POJOs or generate the annotated POJOs from an XSD. I've used in the context of a custom XSD, third party XSD and JAX-WS and it was very easy to use (using the JAXB RI 2.1). I'm all for innovation but in the places that need innovating!
    Reply to this Reply to original

  23. Re: re-inventing the wheel[ Go to top ]

    This is not only re-inventing the wheel, but looks very suspiciously like Simple (http://simple.sourceforge.net), however it lacks much of the features of Simple. Everything that you can do with Xmappr can be done with Simple XML serialization, only Simple is a more mature framework with tonnes more capabilities.
    Reply to this Reply to original

  24. not really[ Go to top ]

    This is not only re-inventing the wheel, but looks very suspiciously like Simple (http://simple.sourceforge.net), however it lacks much of the features of Simple.

    Everything that you can do with Xmappr can be done with Simple XML serialization, only Simple is a more mature framework with tonnes more capabilities.
    Simple seems to be oriented towards serialization od Java objects. As such it competes with Xstream, which is more mature and has more features (re-inventing the wheel, anyone?). Xmappr was born out of need to handle XML coming from 3rd parties. A simple comparison: http://groups.google.com/group/xmappr/browse_thread/thread/e5aa7bc4818c693c
    Reply to this Reply to original

  25. Xmappr released[ Go to top ]

    I did a cursory look over the docs. I was wondering if you can map between a class sesli chat and a document when the structures are not equivalent kind of like what can be done fairly easily in JiBX.
    Reply to this Reply to original

  26. Xmappr tool[ Go to top ]

    Xmappr is really an excellent tool because with it anyone can convert xml file into java.Moreover with this tool you will get more benefits when you will work with xml.

    ways to quite smoking

    Reply to this Reply to original

  27. hui[ Go to top ]

    Fertomid forcertain female infertility and used to treat conditions prescribed by your doctor. http://buyfertomid.org/ ">fertomid

    Reply to this Reply to original