YAAEF

I’m officially introducing this terminology: YAEEF, an acronym for Yet Another Adobe Epic Fail.

After mopping up the regressions introduced by the SOAP refactoring, I decided to spend some time chasing down artf5630, the bug where having a < or a & in a string (like a company name) broke the application. Preliminary testing revealed that the problem seemed to be on the Flex end of things, as usual. Trying things like creating a company with those characters worked fine if I did it using the NuSoap client (we have a file test.php for checking things like this). So I started looking at debug traces and whatnot and reached the (erroneous) conclusion that the real problem was that NuSoap wasn’t properly deserializing the input it was getting, since it appeared that the NuSoap client didn’t bother serializing the input in the first place.

After an hour or so of fruitless effort trying to figure out where in the NuSoap code one would fix this, I decided to hack around the problem before the input even hit the NuSoap server. Two str_replace calls later and… the NuSoap client blew up in my face. A little more debugging and tracing turned up the fact that the NuSoap client actually was serializing the input, and the NuSoap server was deserializing it appropriately. So finally, I ran a debug trace and discovered that if I input, say <123&456>, Flex was serializing this to &amp;lt;123&amp;amp;456&gt;.

I’m sure you can see the problem there: for some reason, the input was getting serialized twice, so it was impossible for NuSoap to deserialize it properly. Curiously, this occurred for < and &, but not >. Some searching on Google turned up this (if you don’t have an account, use BugMeNot to get a login). Notice: the bug is “closed” with resolution “fixed”, but according to the comments, the problem was discovered in Flex SDK 3.2, persisted in SDK 3.3 (despite the fact that it was supposedly fixed at that point) and apparently SDK 3.4 as well, since it continues to be a problem in SDK 4.0.

Fortunately, the tracker page contained a workaround that I was able to add to the Npdservice constructor that hackfixes the problem. Just another in a LONG line of hackfixes for Adobe’s bugs. The amount of bad code offsets Adobe would need to buy in order to “undo” all of this crap would probably bankrupt the company. It’s truly sad that this amount of epic failure exists in a professional product, especially one that you get charged an arm and a leg to use. I am seriously hoping to never see Flex again after this project is over, and wherever I end up in the future, if anyone is considering using it, I will argue against it until I’m blue in the face.

Advertisement