Dozer 1.3 Released - Java Bean to Java Bean Mapper

Discussions

News: Dozer 1.3 Released - Java Bean to Java Bean Mapper

  1. The dozer development team is proud to announce the release of dozer 1.3. Dozer is an open-source mapper that recursively copies one JavaBean to another, handling potentially complex conversions between types.

    Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level.

    The mapper is used any time you need to take one type of JavaBean and map it to another type of JavaBean. Most field mapping can be done automatically by dozer using reflection, but any custom mapping can be described in XML format. Mapping is bi-directional so only one relationship between classes needs defining. If any property names on both objects are the same you do not even need to do any explicit property mapping for these fields.

    A mapping framework is useful in a layered architecture where you are creating layers of abstraction by encapsulating changes to particular data objects vs. propagating these objects to other layers (i.e. external service data objects, data transfer objects, or internal service data objects). A mapping framework is ideal for using within Assembler type classes that are responsible for mapping from one data object to another. Pick and choose the layers you use mapping carefully. Do not go overboard as there is maintenance and performance costs associated with mapping data objects between layers.

    Some say that DTO is an anti-pattern. Do packages like this mitigate the weaknesses of the DTO pattern?

    Threaded Messages (35)

  2. Very interesting tool. Combined with JDO may result in an interesting database mapping tool ;-)

    bye,
    Luca Garulli
    OrienTechnologies.com (All in one JDO solution)
    Pro-Netics.com (member of Orixo.com, the XML business alliance)
  3. How can we specify a custom converter for a particular field. For example I want to convert a String to an object of type MyType which needs a custom converter.
  4. If the MyType data object has a String constructor, then it will be automatically mapped and you do not need to custom converter. But if you need to use a custom converter, this can be specified in the dozer bean mapping xml file. The mapping xml would look something like the following...

    <customConverters>
      <converter type="somepackage.CustomConverter" >
        <classA>somepackage.MyType</classA>
        <classB>java.lang.String</classB>
      </converter>
    </customConverters>

    If you have already downloaded the Dozer src code, you may want to take a look at MapperTest.testCustomConverterMapping() for a good example. Hope this helps.
  5. Hi,

    I have 2 objects, Object1 and Object2. Object1 has an attribute which is an object named obj3. I am trying to map the attr1 value in obj3 to attr2 in Object2. I have the following mapping:

    &#60;mapping&#62;
      &#60;classA&#62;Object1&#60;&#47;classA&#62;
      &#60;classB&#62;Object2&#60;&#47;classB&#62;
      &#60;field-deep&#62;
        &#60;A>obj3.attr1&#60;&#47;A&#62;
        &#60;B>attr2&#60;&#47;B&#62;
      &#60;&#47;field-deep&#62;
    &#60;&#47;mapping&#62;

    Instead of throwing NullPointerException during runtime when obj3 is null, can it be made to just move on to mapping the next attribute? Also, Dozer throws exception when typo is made in the mapping xml, can it print out what objects and fields it's trying map because it's very hard to debug when the mapping xml is huge.

    Thanks,
    Tang-Hong Lai
  6. You can override the error handling policy for a particular mapping. For example:

    You can set stopOnErrors globally or locally:

    <configuration>
      <stopOnErrors>false</stopOnErrors>
    </configuration>

    <mapping stopOnErrors="true">
    ...
    </mapping>

    If you turn up log4j debugging to debug we print out every field that is mapped.
  7. Hi,I have 2 objects, Object1 and Object2. Object1 has an attribute which is an object named obj3. I am trying to map the attr1 value in obj3 to attr2 in Object2. I have the following mapping:&amp;#60;mapping&amp;#62;&nbsp;&nbsp;&amp;#60;classA&amp;#62;Object1&amp;#60;&amp;#47;classA&amp;#62;&nbsp;&nbsp;&amp;#60;classB&amp;#62;Object2&amp;#60;&amp;#47;classB&amp;#62;&nbsp;&nbsp;&amp;#60;field-deep&amp;#62;&nbsp;&nbsp;&nbsp;&nbsp;&amp;#60;A>obj3.attr1&amp;#60;&amp;#47;A&amp;#62;&nbsp;&nbsp;&nbsp;&nbsp;&amp;#60;B>attr2&amp;#60;&amp;#47;B&amp;#62;&nbsp;&nbsp;&amp;#60;&amp;#47;field-deep&amp;#62;&amp;#60;&amp;#47;mapping&amp;#62;Instead of throwing NullPointerException during runtime when obj3 is null, can it be made to just move on to mapping the next attribute? Also, Dozer throws exception when typo is made in the mapping xml, can it print out what objects and fields it's trying map because it's very hard to debug when the mapping xml is huge.Thanks,Tang-Hong Lai

    The latest release of Dozer validates the mapping XML against an XSD. It will immediately tell you if you have a problem in your XML.
  8. I found that most of the time I am using the field-deep tag and often time the deep property is either a List or an Array that needs to be mapped to another List. Currently the work around is to use a converter or create additional object that wraps a List to get the result, not very straight forward. It would be great if the field-deep tag supports sourceTypeHint and destinationTypeHint. :)
  9. We will create a test for this use case and let you know the results. It sounds like a good piece of functionality to add to Dozer. Thanks for the feedback.
  10. I was able to reproduce your issue and I identified the Dozer code changes required to support this use case. I will talk with the other Dozer developers about the change and let you know when we can release this functionality. The code change is small, so I am optimistic that we can deliver this functionality soon.
  11. It's great to hear that sourceTypeHint and destinationTypeHint will be available for the field-deep tag. It'd be even better if both field tag and field-deep tag can co-exist within the same mapping tag. :-) Hopefully I am not asking for too much.
  12. Wow, that sounds like a really useful tool!
  13. Yes, but... GPL?[ Go to top ]

    Wow, that sounds like a really useful tool!
    Agreed. But I'll never use it because of the GPL license. Why not putting a little 'L' in front of it?
  14. Yes, but... GPL?[ Go to top ]

    Great point. After doing some investigation I now understand the nuances of GPL vs. LGPL. We will release dozer under LGPL tonight.

    Thanks for your feedback.
  15. We have released dozer with an Apache License, V2.0. Enjoy.
  16. Yes, but... GPL?[ Go to top ]

    Amazing! I didn't think it would have been so easy... thank you!
  17. XSnapshot[ Go to top ]

    You might want to take a look at XSnapshot. (http://xsnapshot.sf.net)

    XSnapshot addresses another aspect of working with DTOs, focusing on generating them from metadata (XDoclet tags) in your domain model. You can do some very cool things with it, like generate Struts form beans, and spit out serialization-friendly objects for use with SOAP.

    XSnapshot also generates some helper classes for the conversions back and forth, although you could probably also use dozer with it too.
  18. Another Tool[ Go to top ]

    Check out SchemaWare's Java2JavaMapper Tool. That supports the following mapping
    1. JAVA Beans <-> JAVA Beans
    2. XML <->XML
    3. JAVA Beans <-> Database
    4. XML <-> Database.
    It also comes with nice drag and drop GUI tool.
  19. Another Tool[ Go to top ]

    Check out SchemaWare's Java2JavaMapper Tool. That supports the following mapping1. JAVA Beans <-> JAVA Beans2. XML <->XML3. JAVA Beans <-> Database4. XML <-> Database.It also comes with nice drag and drop GUI tool.

    Looks like a nice tool. We are in the process of designing a UI to help with the creation of the mapping XML (when its actually needed). Of course, it looks like Dozer does already have the advantage over price... :)
  20. beanlib[ Go to top ]

    For simple JavaBean to JavaBean population and replication, handling the entire object graph including circular references, check out

    http://sourceforge.net/projects/beanlib

    :)
  21. beanlib[ Go to top ]

    For simple JavaBean to JavaBean population and replication, handling the entire object graph including circular references, check out [...]

    Well, I don't expect a 1000 pages manual for an OS product, but at least an html page that says what the library is supposed to do!

    sf.net summary says:
    Java Bean Library. A general purpose library for manipulating Java Beans.
    That is even shorter than your post!
  22. http://otom.dev.java.net/
  23. http://otom.dev.java.net/

    Just want to make a point here: A object to object mapping framework plays a really really small role in the overall runtime of a Java/J2EE system, but should deal with eliminating the laborious work of mapping objects one to another - DTO or non-DTO does not matter.

    In other words, if possible, the framework's runtime component should be avoided and instead fall back to code generation. This in my opinion leads to widespread adoption, especially when you are developing a small non-apache framework. This is the approach I have taken in developing OTOM -
    O
    bject
    T
    o
    O
    bject
    M
    apping Framework

    I must admit that the framework is still in 0.5 - still a lot needs to be done, but I have used it in projects with success. With Eclipse, What I do is: I configure a builder that runs before the actual Java compilation of the classes. When I do a Project --> Clean --> Selected projects, the required classes are generated before compilation (Just like XDoclet, Well you get the idea)

    Cheers,
    Srikanth
  24. The screwy format in previous posting was not intended. Sorry
  25. Issues using dozer[ Go to top ]

    I found 2 issues when I was using the dozer in my project (a Spring application) and I want to inject the mapping file name to my wrapper bean and call Mapper.addMappingFile() method to load the file. First of all dozer always looks for beanmapping.xml and secondly it throws an exception when the mapping file is found in a jar file.
  26. I found 2 issues when I was using the dozer in my project (a Spring application) and I want to inject the mapping file name to my wrapper bean and call Mapper.addMappingFile() method to load the file. First of all dozer always looks for beanmapping.xml and secondly it throws an exception when the mapping file is found in a jar file.


    Caused by: java.io.FileNotFoundException: file:\D:\Projects\dist\common.jar!\beanmapping.xml (The filename, directory name, or volume label syntax is incorrect)
  27. Good catch. The first problem was fixed with 1.3.2. Dozer was giving an incorrect error...saying it could not find the beanmapping.xml file. As far as having the mapping file in a jar, I just reproduced that and will put in a fix today. Look for 1.3.3.

    Thanks,

    Franz
  28. This has been fixed in 1.3.3. Please go to SF for the latest releases.

    Thanks for looking.

    Franz
  29. Looks like the issue is partially fixed. The issue is fixed when loading the default dozerBeanMapping.xml file and the issue still exists when additional mapping files are loaded programatically (Mapper.addMappingFile("beanConversionMapping.xml");).


    [junit] (conversion.ConversionServiceImpl 60 ) Loading file at location: jar:file:/D:/Projects/EDB/Common/dist/common.jar!/beanConversionMapping.xml
  30. So here's the skinny. By adding a "/" to your file name it will be added. i.e. Mapper.addMappingFile("/myTest.xml");

    Currently, dozer is designed to always have a default mapping file (i.e. dozerBeanMapping.xml). You can then add other mapping files.

    Dozer 1.4 will support more robust ways to add/subtract mapping files.
  31. I ran into a problem where I tried to map fields in my base class, but they were not mapped because the base class was not found in the mapping file.

    It would be desireable to have the fields in the base class mapped rather than having to specify fields in each of the sub classes.
  32. This functionality will be handled in 1.4 which will be released in the next week or so. You will be able to map the base class and basically inherit all of the fields for your other mappings.
  33. I ran into a problem where I tried to map fields in my base class, but they were not mapped because the base class was not found in the mapping file.It would be desireable to have the fields in the base class mapped rather than having to specify fields in each of the sub classes.


    The latest release of Dozer handles this problem nicely. The online docs show the sample mapping xml. Check it out if you have the time.
  34. In version 1.4, it seems that Dozer is checking whether there is mapping in the xml for base class for both source and destination and map the base classes if there is.

    This doesn't solve totally solve the problem. It won't work if I have a bean class that I want to map to another object called subObject which has a base class called baseObject. If the code is getting base class of both source and destination, baseObject won't get populated because there's no mapping for Object and BaseObject in the xml.
  35. Dozer feedback[ Go to top ]

    The dozer team would love to hear how developers are using Dozer (for better or for worse). In fact, we would like to post some of the feedback on the dozer website. If anybody wants to contribute, either post here, or on the forums hosted at the sourceforge Dozer site. Thanks!
  36. Dozer and XMLBeans[ Go to top ]

    Hello,
    I am writing a data plumbing framework that is XSD centric in representation of the data as it flows to the system (i.e. using DTO that are generated based on xsd and can create XML or use XML to populate themselves). I am doing this with XMLBeans to generate the Beans from predefined XSDs and I am trying to map the strut action forms to the XMLBean generated value objects. Has anyone tried this before?

    The issues is that the XMLBean generated value object is an interface backed by an implementation. The interface has a factory that creates the implmentation. The implementation does not have any variables defined but gets the data from the XML Document (I havent looked closely as to how).

    One idea to make it work would be if in the mapping file I could define the accessors to access the data for mapping. This would allow the implementation to do its thing under the cover and the dozer could work at the interface level. Is it possible to define accessor instead of variables to map the data?
    Thanks for your help
    Anuj Vohra