#12 Improve error messages for nested transformations

[Matt Sgarlata]

When an error occurs during a deep copy of an object graph, the error messages are confusing. Here is an example:

net.sf.morph.transform.TransformationException: Error copying source [com.spider.cms.hdao.impl.PerformanceChartHDao@1, com.spider.cms.hdao.impl.PerformanceChartHDao@2, com.spider.cms.hdao.impl.PerformanceChartHDao@1] (class org.hibernate.collection.PersistentList) to destination [com.spider.cms.hdao.impl.PerformanceChartHDao@1, com.spider.cms.hdao.impl.PerformanceChartHDao@2, com.spider.cms.hdao.impl.PerformanceChartHDao@1] (class org.hibernate.collection.PersistentList) at net.sf.morph.transform.transformers.BaseTransformer.copy(BaseTransformer.java:402) at net.sf.morph.transform.transformers.SimpleDelegatingTransformer.copyImpl(SimpleDelegatingTransformer.java:245) at

It would be nice if we could spit out something better like "Error copying property some.nested.path where source was ___ and destination was ___" or perhaps "Error copying property 'path' of object at path 'some.nested' where source was __ and destination was ___"

Right now the error message looks like it could be something wrong with Morph when really that's not the case at all. The error messages need to give more context of where we are in the graph that the error is happening.

[Matt Benson]

Logged In: YES
user_id=120761
Originator: NO

I think it would be nice in general to have a facility in Morph whereby one could determine the current position in an object graph. I'm thinking it might be fairly easy to do this with a ThreadLocal stack of property names and have been kind of letting this idea cook for awhile to figure out how to do this as non-invasively as possible, maybe by providing an aspect to be applied to any NodeCopier (this would probably be very easy to Spring-wire, for example). Maybe if this were available message-building code could query some known threadlocal to learn whether the node-tracker was in use, and augment the created messages accordingly.

[Matt Benson]

Logged In: YES
user_id=120761
Originator: NO

I think the transformerName/reflectorName properties go a long way here, since they show up in logging.

[Matt Sgarlata]

Logged In: YES
user_id=1161666
Originator: YES

That sounds like a great idea! Actually, in order to avoid infinite loops when transforming cyclic object graphs, the SimpleDelegatingTransformer already keeps track of 2 variables as ThreadLocals:

visitedSourceToDestinationMapThreadLocal - keeps track of transformations that have already been performed so that they are not performed again
stackDepthThreadLocal - keeps track of how far down we are in the stack so that when a transformation is complete, we can clear out the visitedSourceToDestinationMapThreadLocal and avoid a memory leak

Instead of keeping track of stack depth, it could be possible to change the ThreadLocal to keep track of property names instead.

I think the Spring idea is cool too but it has the disadvantage of introducing a dependency on Spring. One of the places I currently use Morph is inside a Java applet, so introducing a dependency on Spring would really make the applet a ton bigger!