[SPR-130] Corrected invalid use of DocBook <interface/> element.

This commit is contained in:
Rick Evans
2007-05-28 12:11:50 +00:00
parent e1f4f0abaf
commit 33a6c2b95b
3 changed files with 6 additions and 6 deletions

View File

@@ -121,8 +121,8 @@ public class WebServiceClient {
In order to facilitate the sending of plain Java objects, the <classname>WebServiceTemplate</classname>
has a number of send methods that take an object as an argument for a message's data content.
The method <methodname>marshalSendAndReceive</methodname> in <classname>WebServiceTemplate</classname>
delegates the conversion of the request object to XML to a <interface>Marshaller</interface>, and
the conversion of the response XML to an object to an <interface>Unmarshaller</interface>.
delegates the conversion of the request object to XML to a <interfacename>Marshaller</interfacename>, and
the conversion of the response XML to an object to an <interfacename>Unmarshaller</interfacename>.
For more information about marshalling and unmarshaller, refer to <xref linkend="oxm"/>.
By using the marshallers, you and your application code can focus on the business object that is being
sent or received and not be concerned with the details of how it is represented as XML.
@@ -133,7 +133,7 @@ public class WebServiceClient {
</section>
<section>
<title>
<interface>WebServiceMessageCallback</interface>
<interfacename>WebServiceMessageCallback</interfacename>
</title>
<para>
To accommodate the setting of SOAP headers, and other settings on the message, the

View File

@@ -68,7 +68,7 @@ public interface Marshaller {
void marshal(Object graph, Result result)
throws XmlMappingException, IOException;
}]]></programlisting>
The <interface>Marshaller</interface> interface has one main method, which marshals the given
The <interfacename>Marshaller</interfacename> interface has one main method, which marshals the given
object to a given <interfacename>javax.xml.transform.Result</interfacename>. Result is a tagging
interface that basically represents an XML output abstraction: concrete implementations wrap various XML
representations, as indicated in the table below.

View File

@@ -108,7 +108,7 @@
<section>
<title><classname>MessageDispatcherServlet</classname></title>
<para>
The <classname>MessageDispatcherServlet</classname> is a standard <interface>Servlet</interface> which
The <classname>MessageDispatcherServlet</classname> is a standard <interfacename>Servlet</interfacename> which
conveniently extends from the standard Spring Web <classname>DispatcherServlet</classname>, and wraps
a <classname>MessageDispatcher</classname>. As such, it combines the attributes of these into one:
as a <classname>MessageDispatcher</classname>, it follows the same request handling flow as described
@@ -175,7 +175,7 @@
<para>
As you can see, the <interfacename>PayloadEndpoint</interfacename> interface defines a single method that
is invoked with the XML payload of a request (typically the contents of the SOAP Body, see
<xref linkend="soap-message"/>). The returned <interface>Source</interface>, if any, is stored in the
<xref linkend="soap-message"/>). The returned <interfacename>Source</interfacename>, if any, is stored in the
response XML message. While the <interfacename>PayloadEndpoint</interfacename> interface is quite abstract,
Spring-WS offers a lot of endpoint implementations out of the box that already contain a lot of the
functionality you might need. The <interfacename>PayloadEndpoint</interfacename> interface just defines the