2

One thing that prevents from using a binding technology like JAXB, instead of a classic dom/sax-based xml technology is the fact that, when reading xml, it seems to be strongly oriented to instantiate the classes that it manages.

Many times, i want to read values from xml and set them to properties of already created instances.
Is there a simple way to tell JAXB that it has to apply values to the class that i have instead of create a new one?

AgostinoX
  • 7,477
  • 20
  • 77
  • 137
  • 1
    In your use case what is the link between the XML and the existing instances (I.e an ID property)? – bdoughan Sep 15 '11 at 12:46
  • The problem is that if jaxb-based libraries want to create instances, they will be not suitable where classes are instantiated by another framework. Think to spring where the container instantiates the beans. Or either swing, where I often want to save some properties of gui components, but I want also to create them myself (or my ide wants so). My idea was a "per class" approach, where i pass to jaxb the class (or a "factory" that returnes back my class), an xml node and it loads attributes into class properties. – AgostinoX Sep 15 '11 at 13:08
  • I'm still trying to grasp the use case. Is it that you have existing classes that you want to map to XML, or that you have existing instances of classes that you want JAXB to populate into? – bdoughan Sep 15 '11 at 13:26
  • 2
    I have existing instances I want JAXB populate into. – AgostinoX Sep 15 '11 at 13:45
  • 1
    The approach given by @Bozho (or something similar) is what you will need to do for now. This is an interesting possible extension for JAXB. I'm the EclipseLink JAXB (MOXy) lead, if you care to enter an enhancement request for this then you can do so at this link: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EclipseLink – bdoughan Sep 15 '11 at 16:50

1 Answers1

2

Use the JAXB objects as DTOs. Then you can use PropertyUtils.copyProperties(..) / BeanUtils.copyProperties(..) (from commons-beanutils) to transfer the properties to your already-partially-populated objects.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • Ok, but the DTO tree, from an architectural point of view is like build a typed dom, isn't it? – AgostinoX Sep 16 '11 at 07:51
  • I didn't understand the comment – Bozho Sep 16 '11 at 08:02
  • Ok, I explain it a little more. When you use a xml library based on some kind of dom (dom, jdom, dom4j, xom) you build an in-memory tree that represents the xml file. Then you get from the tree the values you want. Using DTO, you build an in-memory tree that instead of being made of "Node" objects (or "Element" and "Attribute" objects or whatsoever depending on the specific library in use) is simply made of my ClassA, ClassB, that are my DTO classes. – AgostinoX Sep 16 '11 at 08:21
  • This is a bit a contortion. But offers at least two advantages 1) the specialized DTO classes may contain custom validation logic if needed 2) non-technical reason: jaxb is a standard, while jdom, dom4j, xom are not and the "standard" dom implementation is considered to be poorly usable. Since the DOM "chaos" is a real pain, letting jaxb cover that area can let me rest a little easier. – AgostinoX Sep 16 '11 at 08:43