In my previous post I pointed to the BlazeDS classes that need to be replaced in order to prevent ActionScript Number.NaN from turning into Long or Integer zeroes on the MessageBroker side. The recommendation boiled down to re-jaring flex-messaging-core.jar or placing the modified classes somewhere earlier in the application server’s classpath. If neither option is allowed, you may configure your endpoint with the custom type marshaller, like the one below:
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel"> <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"> </endpoint> <properties> <serialization> <type-marshaller>com.farata.messaging.io.CustomTypeMarshaller</type-marshaller> </serialization> </properties> </channel-definition> |
In BlazeDS 4 you will base your type marshaller on flex.messaging.io.ASTranslator, in BlazeDS 3 they already have one level of extension called Java15TypeMarshaller, so build on top of that one:
package com.farata.messaging.io; import com.farata.messaging.io.amf.translator.decoder.NumberDecoder; import flex.messaging.io.amf.translator.decoder.DecoderFactory; // For BlazeDS 4 you should extend flex.messaging.io.ASTranslator public class CustomTypeMarshaller extends flex.messaging.io.Java15TypeMarshaller { private static final NumberDecoder numberDecoder = new NumberDecoder(); public Object convert(Object source, Class desiredClass) { if ( DecoderFactory.isNumber(desiredClass)){ return numberDecoder.decodeObject(source, desiredClass); }else{ return super.convert(source, desiredClass); } } } |
This route does not require neither server-level deployment nor modification of the flex-messaging-core.jar.
Please note that in my example I repackaged NumberDecoder as com.farata.messaging.io.amf.translator.decoder.NumberDecoder
I’d like to use this opportunity and invite Flex developers living in Europe to attend our Advanced Flex Master Class in Brussels, Belgium on March 1 and 2, 2010.
Victor Rasputnis
quinten said,
March 18, 2010 @ 9:56 am
i would also like to tackle the opposite problem. We have Long variables in Java which are null but which are converted to 0 in AS . We would like to map them to NaN in order to differentiate between null and 0.
Is there a way to write a custom encoder ?
Nicolas said,
March 26, 2010 @ 3:56 am
There is a way to deal with your porblem, but it is tricky.
Basically, you need to use a BeanProxy that will look at the return type of your method and based on that and the fact that it is null, return NaN instead.
the tricky part is that you need to register your BeanProxy against the classes that will have to use that customization. So the BlazeDS 3 way as it is done, you’re supposed to have either a common superclass or an interface on all your DTO.
You can find more info on that in that bug : http://bugs.adobe.com/jira/browse/BLZ-305