This topic has not yet been written. The content below is from the topic description.
The easiest way to configure marshalling is to specify nothing at all. This will prompt the remoting invokers to use their default marshaller/unmarshallers. For example, the socket invoker will use the SerializableMarshaller/SerializableUnMarshaller and the http invoker will use the HTTPMarshaller/HTTPUnMarshaller, on both the client and server side. The next easiest way is to specify the data type of the marshaller/unmarshaller as a parameter to the locator url. This can be done by simply adding the key word 'datatype' to the url, such as: socket://myhost:5400/?datatype=serializable This can be done for types that are statically bound within the MarshalFactory, serializable and http, without requiring any extra coding, since they will be available to any user of remoting. However, is more likely this will be used for custom marshallers (since could just use the default data type from the invokers if using the statically defined types). If using custom marshaller/unmarshaller, will need to make sure both are added programmatically to the MarshalFactory during runtime (on both the client and server side). This can be done by the following method call within the MarshalFactory: public static void addMarshaller( String dataType, Marshaller marshaller, UnMarshaller unMarshaller) The dataType passed can be any String value desired. For example, could add custom InvocationMarshaller and InvocationUnMarshaller with the data type of 'invocation'. An example using this data type would then be: socket://myhost:5400/?datatype=invocation One of the problems with using a data type for a custom Marshaller/UnMarshaller is having to explicitly code the addition of these within the MarshalFactory on both the client and the server. So another approach that is a little more flexible is to specify the fully qualified class name for both the Marshaller and UnMarshaller on the locator url. For example: socket://myhost:5400/?datatype=invocation& marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller& unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller This will prompt remoting to try to load and instantiate the Marshaller and UnMarshaller classes. If both are found and loaded, they will automatically be added to the MarshalFactory by data type, so will remain in memory. Now the only requirement is that the custom Marshaller and UnMarshaller classes be available on both the client and server's classpath. Another requirement of the actual Marshaller and UnMarshaller classes is that they have a void constructor. Otherwise loading of these will fail. This configuration can also be applied using the service xml. If using declaration of invoker using the InvokerLocator attribute, can simply add the datatype, marshaller, and unmarshaller parameters to the defined InvokerLocator attribute value. For example: socket://${jboss.bind.address}:8084/?datatype=invocation& marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller& unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller If were using config element to declare the invoker, will need to add an attribute for each and include the isParam attribute set to true. For example: invocation org.jboss.invocation.unified.marshall.InvocationMarshaller org.jboss.invocation.unified.marshall.InvocationUnMarshaller This configuration is fine if the classes are present within the client's classpath. If they are not, can provide configuration for allowing clients to dynamically load the classes from the server. To do this, can use the parameter 'loaderport' with the value of the port you would like your marshal loader to run on. For example: invocation org.jboss.invocation.unified.marshall.InvocationMarshaller org.jboss.invocation.unified.marshall.InvocationUnMarshaller 5401 When this parameter is supplied, the Connector will recognize this at startup and create a marshal loader connector automatically, which will run on the port specified. The locator url will be exactly the same as the original invoker locator, except will be using the socket transport protocol and will have all marshalling parameters removed (except the dataType). When the remoting client can not load the marshaller/unmarshaller for the specified data type, it will try to load them from the marshal loader service running on the loader port, including any classes they depend on. This will happen automatically and no coding is required (only the ability for the client to access the server on the specified loader port, so must provide access if running through firewall). Note. Prior to release 2.5.2, only the parameters in the InvokerLocator were used to configure marshallers and unmarshallers. As of release 2.5.2 the parameters in the configuration map passed to an org.jboss.remoting.Client or org.jboss.remoting.transport.Connector will also be used if the parameter org.jboss.remoting.Remoting.PASS_CONFIG_MAP_TO_MARSHAL_FACTORY (actual value "passConfigMapToMarshalFactory") is set to "true".