[jboss-remoting-commits] JBoss Remoting SVN: r5408 - remoting2/branches/2.x/docs/guide/en.

[jboss-remoting-commits at lists.jboss.org]

Author: ron.sigal at jboss.com
Date: 2009-08-29 23:25:02 -0400 (Sat, 29 Aug 2009)
New Revision: 5408

Modified:
   remoting2/branches/2.x/docs/guide/en/chap5.xml
Log:
JBREM-1145: Added discussion of "remotingContentType" return header.

Modified: remoting2/branches/2.x/docs/guide/en/chap5.xml
===================================================================
--- remoting2/branches/2.x/docs/guide/en/chap5.xml	2009-08-30 03:24:24 UTC (rev 5407)
+++ remoting2/branches/2.x/docs/guide/en/chap5.xml	2009-08-30 03:25:02 UTC (rev 5408)
@@ -703,8 +703,8 @@
     (application/octet-stream).</para>
 
     <para>The handlers receiving http invocations can also set the response
-    code, response message, and response headers. To do this, will need to get
-    the return payload map from the InvocationRequest passed (via its
+    code, response message, response headers, and content-type. To do this, will
+    need to get the return payload map from the InvocationRequest passed (via its
     getReturnPayload() method). Then populate this map with whatever
     properties needed. For response code and message, will need to use the
     following keys for the map:</para>
@@ -2810,7 +2810,7 @@
     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).</para>
-
+    
     <para><emphasis role="bold">Note.</emphasis> Prior to release 2.5.2, only the
     parameters in the <classname>InvokerLocator</classname> were used to configure
     marshallers and unmarshallers.  As of release 2.5.2 the parameters in the
@@ -2819,6 +2819,23 @@
     be used if the parameter
     <code>org.jboss.remoting.Remoting.PASS_CONFIG_MAP_TO_MARSHAL_FACTORY</code>
     (actual value "passConfigMapToMarshalFactory") is set to "true".</para>
+    
+    <bridgehead>Http marshalling</bridgehead>
+    <para>By default, the http, https, servlet, and sslservlet transports use 
+    <classname>org.jboss.remoting.marshal.http.HTTPMarshaller</classname> and
+    <classname>org.jboss.remoting.marshal.http.HTTPUnMarshaller</classname>,
+    which are distinct from their parent classes
+    <classname>org.jboss.remoting.marshal.serializable.SerializableMarshaller</classname>
+    and <classname>org.jboss.remoting.marshal.serializable.SerializableUnMarshaller</classname>
+    only insofar as they treat Strings as a special case in the interest of efficiency.
+    However, prior to release 2.5.2, <classname>HTTPUnMarshaller</classname> incorrectly
+    uses the content-type set by the <classname>ServerInvocationHandler</classname> (if
+    any), which would normally apply to the application payload of a response rather
+    than the type of the envelope.  As of release 2.5.2, this behavior remains the
+    default, but it can be corrected by setting the parameter 
+    <code>org.jboss.remoting.transport.http.HTTPMetadataConstants.USE_REMOTING_CONTENT_TYPE</code>
+    (actual value "useRemotingContentType") to "true".</para>
+
     <bridgehead>Compression marshalling</bridgehead>
 
     <para>A compression marshaller/unmarshaller is available as well which
@@ -6612,6 +6629,16 @@
     should revert to the orginal error handling behavior of returning an error
     message.</para>
 
+    <para><emphasis role="bold">USE_REMOTING_CONTENT_TYPE</emphasis> (actual value
+    is 'useRemotingContentType') - key indicating if 
+    <classname>org.jboss.remoting.marshal.http.HTTPUnMarshaller</classname>
+    should determine that it is reading a String by using the "content-type"
+    return header (if set to "false") or the "remotingContentType" header
+    if set to "true".  The default value is "false", to avoid introducing any
+    inconsistent behavior between versions, but, if the
+    <classname>org.jboss.remoting.ServerInvocationHandler</classname> sets
+    the content-type return header, then this parameter should be set to "true".</para>
+    
     <para>For every http client request made from remoting client, a remoting
     version and remoting specific user agent will be set as a request
     property. The request property key for the remoting version will be