|
52 | 52 | </caption> |
53 | 53 | </mediaobject> |
54 | 54 | </para> |
55 | | - <para> |
| 55 | + <para> |
56 | 56 | When a <classname>MessageDispatcher</classname> is set up for use and a request comes in for that |
57 | 57 | specific dispatcher, said <classname>MessageDispatcher</classname> starts processing the request. The |
58 | 58 | list below describes the complete process a request goes through when handled by a |
|
87 | 87 | Exceptions that are thrown during handling of the request get picked up by any of the endpoint exception |
88 | 88 | resolvers that are declared in the application context. Using these exception resolvers allows you to define |
89 | 89 | custom behaviors (such as returning a SOAP Fault) in case such exceptions get thrown. |
90 | | - </para> |
| 90 | + </para> |
91 | 91 | <para> |
92 | 92 | The <classname>MessageDispatcher</classname> has several properties, for setting endpoint adapters, |
93 | 93 | <link linkend="server-endpoint-mapping">mappings</link>, |
94 | 94 | <link linkend="server-endpoint-exception-resolver">exception resolvers</link>. |
95 | 95 | However, setting these properties is not required, since the dispatcher will automatically detect all of |
96 | 96 | these types that are registered in the application context. Only when detection needs to be overriden, |
97 | 97 | should these properties be set. |
98 | | - </para> |
99 | | - <para> |
100 | | - The message dispatcher operates on a <link linkend="message-context">message context</link>, and not |
101 | | - transport-specific input stream and output stream. As a result, transport specific requests need to read |
102 | | - into a <interfacename>MessageContext</interfacename>. For HTTP, this is done with a |
103 | | - <classname>WebServiceMessageReceiverHandlerAdapter</classname>, which is a Spring Web |
104 | | - <interfacename>HandlerInterceptor</interfacename>, so that the <classname>MessageDispatcher</classname> |
105 | | - can be wired in a standard <classname>DispatcherServlet</classname>. There is a more convenient way to do |
106 | | - this, however, which is shown in the next section. |
107 | | - </para> |
| 98 | + </para> |
| 99 | + <para> |
| 100 | + The message dispatcher operates on a <link linkend="message-context">message context</link>, and not |
| 101 | + transport-specific input stream and output stream. As a result, transport specific requests need to read |
| 102 | + into a <interfacename>MessageContext</interfacename>. For HTTP, this is done with a |
| 103 | + <classname>WebServiceMessageReceiverHandlerAdapter</classname>, which is a Spring Web |
| 104 | + <interfacename>HandlerInterceptor</interfacename>, so that the <classname>MessageDispatcher</classname> |
| 105 | + can be wired in a standard <classname>DispatcherServlet</classname>. There is a more convenient way to do |
| 106 | + this, however, which is shown in the next section. |
| 107 | + </para> |
108 | 108 | <section> |
109 | 109 | <title><classname>MessageDispatcherServlet</classname></title> |
110 | 110 | <para> |
111 | | - The <classname>MessageDispatcherServlet</classname> is a standard <interfacename>Servlet</interfacename> which |
| 111 | + The <classname>MessageDispatcherServlet</classname> is a standard <interfacename>Servlet</interfacename> |
| 112 | + which |
112 | 113 | conveniently extends from the standard Spring Web <classname>DispatcherServlet</classname>, and wraps |
113 | 114 | a <classname>MessageDispatcher</classname>. As such, it combines the attributes of these into one: |
114 | 115 | as a <classname>MessageDispatcher</classname>, it follows the same request handling flow as described |
|
192 | 193 | which explains the whole transformation process in more detail.</para> |
193 | 194 | </section> |
194 | 195 | </section> |
195 | | - </section> |
| 196 | + <section> |
| 197 | + <title>Wiring up Spring-WS in a <classname>DispatcherServlet</classname></title> |
| 198 | + <para> |
| 199 | + As an alternative to the <classname>MessageDispatcherServlet</classname>, you can wire up a |
| 200 | + <classname>MessageDispatcher</classname> in a standard, Spring-Web MVC |
| 201 | + <classname>DispatcherServlet</classname>. |
| 202 | + By default, the <classname>DispatcherServlet</classname> can only delegate to |
| 203 | + <interfacename>Controllers</interfacename>, but we can instruct it to delegate to a |
| 204 | + <classname>MessageDispatcher</classname> by adding a |
| 205 | + <classname>WebServiceMessageReceiverHandlerAdapter</classname> to the servlet's web application |
| 206 | + context: |
| 207 | + <programlisting><![CDATA[<beans> |
| 208 | +
|
| 209 | + <bean class="org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter"/> |
| 210 | +
|
| 211 | + <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> |
| 212 | + <property name="defaultHandler" ref="messageDispatcher"/> |
| 213 | + </bean |
| 214 | +
|
| 215 | + <bean id="messageDispatcher" class="org.springframework.ws.server.MessageDispatcher"/> |
| 216 | +
|
| 217 | + ... |
| 218 | +
|
| 219 | + <bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"/>]]></programlisting> |
| 220 | + Note that by explicitely adding the <classname>WebServiceMessageReceiverHandlerAdapter</classname>, |
| 221 | + the dispatcher servlet does not load the default adapters, and is unable to handle standard Spring-MVC |
| 222 | + <interfacename>Controllers</interfacename>. Therefore, we add the |
| 223 | + <classname>SimpleControllerHandlerAdapter</classname> at the end. |
| 224 | + </para> |
| 225 | + </section> |
| 226 | + </section> |
196 | 227 | <section> |
197 | 228 | <title>Endpoints</title> |
198 | 229 | <para> |
|
0 commit comments