Bean merging in java

Question

Hi, I have got a Jibx bean which is used as both input and output to a webservice. The bean is very large and complex with deep parent child relationship. The webservice does not return the request object but returns a new bean with some properties populated. I would like to merge my request and the response. I tried using Dozer (it just replaces the my request object with the response i.e. the original request properties are lost! Ditto for BeanUtils.copyProperties). The object graph is too big and deep to do a isNull check on all the properties.

I have considered converting the beans into XMLs and merging them using the EL4J XML Merge any other suggestions.

Answer 1

By "too big and deep to do a isNull check" I'm assuming that you don't want to hardcode those checks. Nor should you.

However, the beautiful thing about beans is that they can be inspected, and you can write an automated check to work your way through the object graph, check for null, and update if not.

Yes, that's CPU intensive. But certainly no more CPU intensive than generating XML and attempting to merge it.

Answer 2

As the object is a bean, why not associate the bean with the request and when replying use the request bean? I'm not advocating pushing objects that might just be interface objects deep into your system, but keeping hold of the request bean and making it the response bean too.

I'm not sure what I understand the deepness argument either, but if the input layout means that the logic to populate the response is complex you might want to build up the response population code before the properties are calculated: as the system is determining which properties to calculate it can also build up a strategy for placing those properties back into a response bean. This might be as simple as a strategy pattern, in more complex situations you might consider a bytecode modification library.

Another approach would be to simplify your interface so the properties in the XML are similar and the "deepness" is removed: making all properties similar would then allow property checking and population to be managed with a simple loop.

Converting to XML defeats the object somewhat of using the framework in the first place. Perhaps, if XML is easier Jibx is not the easiest solution for the problem. What are you able to change in your specification?

Answer 3

we can use dozer with a map-null false attribute from source to destination? only the not nulls are copied?wont it solve the problem?