AMF response and typed classes
Hi all,
First of all, I would like to congratulate the Eviware team for the effort they put on soapUI/loadUI. Unless I'm missing something, it seems that it's the only viable tool to perform functional and load tests against an AMF based server.
I'm in the process of setting up these type of tests on a Jspresso based application (Flex frontend / BlazeDS backend). I'm succesfully injecting my AMF requests and now, I need to define assertions (either XPath or even Script). I struggled all day long to figure out why I couldn't get nicely formatted XML as demonstrated using the flexsample application in the AMF tutorial. Whatever I'm trying (AMFConnection.registerAlias, my application jar in ext directory, ...), I always get a response made of generic AS objects instead of my own application classes. This makes assertion implementation really painful.
After a little more digging into the soapUI source code, and some remote debugging, here are my findings and how I implemented a workaround in case it might help others :
1/ Adobe AMFConnection is not used. SoapUIAMFConnection is used instead and there is no relationship between both.
2/ SoapUIAMFConnection hardcodes instantiateTypes=false. Since it's done in the internalConnect() method, there is no way to re-enable instantiateTypes=true before the request is submitted. This instantiateTypes field is the one that enables strong types deserialization in the AMF unmarshaller.
3/ The Adobe sample from the tutorial works fine because Adobe hardcodes that all flex.* classes get deserialized using string types instead of the generic ASObject, thus bypassing instantiateTypes=false. That explains why there is nothing to do to get a cleanly formatted XML when dealing with flex.samples.product.Product domain object.
As a quick and dirty test, I've replaced the SoapUIAMFConnection with a version that does not disable instantiateTypes in the internalConnect() method, and everything ran fine as expected. I can now see my objects properly deserialized and a nice XML against which I can easily perform my assertions.
One final hack I had to do is to put my application jar(s) into the lib directory and not into the bin/ext directory (same thing had to be done with the flexsample.jar of the tutorial). The bin/ext directory made my classes available to groovy scripts (classloader) but not to AMF deserializer. The AMF deserializer must be loaded by the application classloader that does not see the jars in the bin/ext directory.
So, finally, the question is : why did strong types deserialization has been disabled in an hardcoded way in SoapUIAMFConnection ? Is there any chance that this can be made configurable ?
Thanks in advance for your insights.
Vincent
First of all, I would like to congratulate the Eviware team for the effort they put on soapUI/loadUI. Unless I'm missing something, it seems that it's the only viable tool to perform functional and load tests against an AMF based server.
I'm in the process of setting up these type of tests on a Jspresso based application (Flex frontend / BlazeDS backend). I'm succesfully injecting my AMF requests and now, I need to define assertions (either XPath or even Script). I struggled all day long to figure out why I couldn't get nicely formatted XML as demonstrated using the flexsample application in the AMF tutorial. Whatever I'm trying (AMFConnection.registerAlias, my application jar in ext directory, ...), I always get a response made of generic AS objects instead of my own application classes. This makes assertion implementation really painful.
After a little more digging into the soapUI source code, and some remote debugging, here are my findings and how I implemented a workaround in case it might help others :
1/ Adobe AMFConnection is not used. SoapUIAMFConnection is used instead and there is no relationship between both.
2/ SoapUIAMFConnection hardcodes instantiateTypes=false. Since it's done in the internalConnect() method, there is no way to re-enable instantiateTypes=true before the request is submitted. This instantiateTypes field is the one that enables strong types deserialization in the AMF unmarshaller.
3/ The Adobe sample from the tutorial works fine because Adobe hardcodes that all flex.* classes get deserialized using string types instead of the generic ASObject, thus bypassing instantiateTypes=false. That explains why there is nothing to do to get a cleanly formatted XML when dealing with flex.samples.product.Product domain object.
As a quick and dirty test, I've replaced the SoapUIAMFConnection with a version that does not disable instantiateTypes in the internalConnect() method, and everything ran fine as expected. I can now see my objects properly deserialized and a nice XML against which I can easily perform my assertions.
One final hack I had to do is to put my application jar(s) into the lib directory and not into the bin/ext directory (same thing had to be done with the flexsample.jar of the tutorial). The bin/ext directory made my classes available to groovy scripts (classloader) but not to AMF deserializer. The AMF deserializer must be loaded by the application classloader that does not see the jars in the bin/ext directory.
So, finally, the question is : why did strong types deserialization has been disabled in an hardcoded way in SoapUIAMFConnection ? Is there any chance that this can be made configurable ?
Thanks in advance for your insights.
Vincent