Friday, December 6, 2013

Remoting Landmine without a stack trace or debug ability

Summary: 

While using AMF remoting, if you get the following error: 

TypeError: Error #1034: Type Coercion failed: cannot convert Object@1456c7b9 to mx.messaging.messages.IMessage

And you've overridden the  hashcode to your java VO objects, you will end up in an un-debuggable situation. 

Solution:  Remove the hashcode override. 

BackStory:

We are migrating database schemas, so I had set up unit tests to compare the results from one schema to the other. I am using JUnit and assertEquals. 
According to the documentation, I should override the equals() method on each object, as that is what the assertEquals uses for the comparison. This was tedious, but then I discovered that Eclipse had a generate equals() and hashcode() methods. Eclipse comments say to always include hashcode when overriding equals. Ok. I confirmed that on google, all things checked out. 

What happened though, is that serializing from Java to Flex went fine, but on the return trip --- BOOM. 
The error was an UncaughtErrorEvent.UNCAUGHT_ERROR. The request made it out, according to Charles webproxy, but never actually made it to the endpoint on the other side (Based on the debugging breakpoint). Since it never made it to the service, the normal fault responder didn't fire. Fortunately, I'm trapping all uncaught error messages in Flex. There was no stack trace in Flex or in Java. Just this error thrown from somewhere.

The only information I could gather from Charles was that it was a StackOverflowError. 

I only discovered this information by rolling back one commit at a time, then cherry-picking one file at a time, then one method at a time. Painful! 

If you run into this, I hope that I've included enough keywords that you find it quickly and don't waste a whole day like I did. 




No comments:

Post a Comment