The other day I was spending some time with a client of mine who ran into an issue with a Flex Remoting endpoint in Livecycle/ADEP
Essentially what happened was that within an object tree supposed to be sent from the Flex application to a Livecycle endpoint contained a lot of unexpected null references. Monitoring the AMF remoting traffic with Charles showed however that the data was serialised fine on the Flex side of things. At the other end of the wire though, something clearly went wrong. Even more confusing was that the serialisation seemed to work fine for non-complex data types which led us to the suspicion that the conversion of ArrayCollections to Java generics was setup incorrectly.
Without elaborating on details of coding and configuration switches that can modify how all that works in depth (hint: IExternalizable and java.io.Externalizable are your friends…), I rather want to explain some other configuration settings that a lot of people wouldn’t be aware of, but that are extremely helpful when you run into a possible serialisation problem.
First of all make sure you’re aware of the very useful documentation on how the serialisation resp. deserialisation between Java and ActionScript works. The main configuration file of Flex remoting in Livecycle/ADEP is (as in BlazeDS or stand alone LCDS) is the so called services-config.xml. What we’re essentially dealing with is the setup of the communication channel (AMF Remoting in my case). The XML configuration for the channel setup contains (among other things) a <serialization> element.
Of particular interest for debugging are ignore-property-errors (which if not specified defaults to true) and log-property-errors (which – you might guess it – if not specified defaults to false). If ignore-property-errors is set to true, the serialisation mechanism will (as good as it can) try to match the properties of the DTOs between ActionScript and Java types (and potentially “ignore property errors”). This should ring a bell as the problem manifested itself as unexpected null values. Indeed – after having looked into various other possible causes of the error, toggling the two switches above created log entries that clearly showed that the remoting endpoint wasn’t able to access the properties in question.
In this case the actual fix was simple – the properties in question on the Java end were set to protected and the (JAXB-generated) code didn’t provide an explicit setter function. Fixing that – serialization worked fine again.
Can you elaborate on any issues you had enabling Logging in the LCES (rather than DS) bundle of DS?
Cheers!
Comments on this entry are closed.