Using Custom Type Marshallers in BlazeDS

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>clear.messaging.io.amf.translator.NullkeepingASTranslator</type-marshaller>
               </serialization>
           </properties>    
       </channel-definition>

In BlazeDS 4 you will base your type marshaller on flex.messaging.io.ASTranslator:
public class NullkeepingASTranslator extends
    flex.messaging.io.amf.translator.ASTranslator
{
    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.

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

2 thoughts on “Using Custom Type Marshallers in BlazeDS

  1. 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 ?

  2. 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

Comments are closed.