The BlazeDS RemotingService has traditionally been configured by the inclusion of a remoting-config.xml file in the BlazeDS XML configuration. When using only Spring-managed remoting destinations, this config file can be left out completely as the inclusion of the message-broker tag in your Spring configuration will cause the RemotingService to be configured with sensible defaults if none already exists at startup time. The end result is essentially equivalent to including the following minimal remoting-config.xml in your BlazeDS configuration:

<?xml version="1.0" encoding="UTF-8"?>
<service id="remoting-service"
    class="flex.messaging.services.RemotingService">

    <adapters>
        <adapter-definition id="java-object" 
            class="flex.messaging.services.remoting.adapters.JavaAdapter" 
            default="true"/>
    </adapters>

    <default-channels>
        <channel ref="my-amf"/>
    </default-channels>
    
</service>    	
    	

Note that this assumes that there is already an equivalent application-wide default-channels configuration. It is recommended that you set the desired service-specific channels (see example below) if not relying on an application-wide default setup. If no application-wide defaults exist, a best guess will be made by configuring the first available channel from the MessageBroker that uses an AMFEndpoint as the default for the RemotingService.

If you wish to have more explicit control over the defaults that will be set on the RemotingService, you can customize them via the remoting-service child element of the message-broker tag. For example:

<flex:message-broker>
	<flex:remoting-service default-adapter-id="my-default-remoting-adapter" 
	    default-channels="my-amf, my-secure-amf" />
</flex:message-broker>
		

If you have an existing remoting-config.xml for a legacy BlazeDS application, the RemotingDestinationExporter will be able to work transparently with it, allowing you to gradually migrate to all Spring-managed remoting destinations.