From a45d33a158a18e43287a3b6941018f05c1908c46 Mon Sep 17 00:00:00 2001 From: Costin Leau Date: Tue, 4 May 2010 18:49:09 +0000 Subject: [PATCH] SPR-7159 + fix several typos --- spring-framework-reference/src/remoting.xml | 28 ++++++++++----------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/spring-framework-reference/src/remoting.xml b/spring-framework-reference/src/remoting.xml index e3433f6cc64..9b327207aa6 100644 --- a/spring-framework-reference/src/remoting.xml +++ b/spring-framework-reference/src/remoting.xml @@ -10,7 +10,7 @@ Spring features integration classes for remoting support using various technologies. The remoting support eases the development of remote-enabled services, implemented by your usual (Spring) POJOs. - Currently, Spring supports four remoting technologies: + Currently, Spring supports the following remoting technologies: Remote Method Invocation (RMI). Through the use of the RmiProxyFactoryBean and the @@ -222,7 +222,7 @@ public class AccountServiceImpl implements AccountService { Using Spring's DispatcherServlet principles, as known from Spring Web MVC usage, you can easily wire up such a servlet exposing your services. First we'll have to create a new servlet in your - application (this an excerpt from + application (this is an excerpt from 'web.xml'): <servlet> @@ -358,7 +358,7 @@ public class AccountServiceImpl implements AccountService { <property name="authorizedRoles" value="administrator,operator"/> </bean> - This an example where we explicitly mention the + This is an example where we explicitly mention the BeanNameUrlHandlerMapping and set an interceptor allowing only administrators and operators to call the beans mentioned in this application context. @@ -376,7 +376,7 @@ public class AccountServiceImpl implements AccountService { Exposing services using HTTP invokers As opposed to Burlap and Hessian, which are both lightweight - protocols using their own slim serialization mechanisms, Spring Http + protocols using their own slim serialization mechanisms, Spring HTTP invokers use the standard Java serialization mechanism to expose services through HTTP. This has a huge advantage if your arguments and return types are complex types that cannot be serialized using the serialization @@ -393,7 +393,7 @@ public class AccountServiceImpl implements AccountService {
Exposing the service object - Setting up the HTTP invoker infrastructure for a service objects + Setting up the HTTP invoker infrastructure for a service object much resembles the way you would do using Hessian or Burlap. Just as Hessian support provides the HessianServiceExporter, Spring's HttpInvoker @@ -439,10 +439,10 @@ public class AccountServiceImpl implements AccountService { <url-pattern>/remoting/AccountService</url-pattern> </servlet-mapping> - f you are running outside of a servlet container and are using + If you are running outside of a servlet container and are using Sun's Java 6, then you can use the built-in HTTP server implementation. - You can configure the SimpleHttpServerFactoryBean together with a - SimpleHttpInvokerServiceExporter as is shown in this example: + You can configure the SimpleHttpServerFactoryBean together with a + SimpleHttpInvokerServiceExporter as is shown in this example: <bean name="accountExporter" class="org.springframework.remoting.httpinvoker.SimpleHttpInvokerServiceExporter"> @@ -619,7 +619,7 @@ public class AccountServiceEndpoint extends ServletEndpointSupport implements Re Where serviceInterface is our remote business interface the clients will use. wsdlDocumentUrl is - the URL for the WSDL file. Spring needs this a startup time to create + the URL for the WSDL file. Spring needs this at startup time to create the JAX-RPC Service. namespaceUri corresponds to the targetNamespace in the .wsdl file. serviceName corresponds to the service name in the .wsdl file. @@ -1000,7 +1000,7 @@ public class AccountServiceEndpoint { Exposing web services using XFire XFire is a lightweight SOAP library, hosted by Codehaus. Exposing - XFire is done using a XFire context that shipping with XFire itself in + XFire is done using a XFire context that is shipping with XFire itself in combination with a RemoteExporter-style bean you have to add to your WebApplicationContext. As with all methods that allow you to expose service, you have to create a @@ -1226,12 +1226,12 @@ public class Client { Considerations when choosing a technology Each and every technology presented here has its drawbacks. You - should carefully consider you needs, the services your exposing and the + should carefully consider your needs, the services you are exposing and the objects you'll be sending over the wire when choosing a technology. When using RMI, it's not possible to access the objects through the HTTP protocol, unless you're tunneling the RMI traffic. RMI is a fairly - heavy-weight protocol in that it support full-object serialization which + heavy-weight protocol in that it supports full-object serialization which is important when using a complex data model that needs serialization over the wire. However, RMI-JRMP is tied to Java clients: It is a Java-to-Java remoting solution. @@ -1402,7 +1402,7 @@ if (HttpStatus.SC_CREATED == post.getStatusCode()) { response HTTP Location header where the newly created object can be found. In case of an exception processing the HTTP request, an exception of the type RestClientException will be - thrown, this behavior can be changed by plugging in another ResponseErrorHandler + thrown; this behavior can be changed by plugging in another ResponseErrorHandler implementation into the RestTemplate. Objects passed to and returned from these methods are converted to @@ -1495,7 +1495,7 @@ URI location = template.postForLocation(uri, booking, "1"); Dealing with request and response headers Besides the methods described above, the RestTemplate - also has the exchange method, which can be + also has the execute method, which can be used for arbitrary HTTP method execution based on the HttpEntity class.