diff --git a/src/docbkx/client.xml b/src/docbkx/client.xml index a9a1cc78..a1fe6dae 100644 --- a/src/docbkx/client.xml +++ b/src/docbkx/client.xml @@ -11,12 +11,12 @@ The package org.springframework.ws.client.core provides the core functionality for using - the client-side access API. It contains template classes that simplifies the use of Web services, much like + the client-side access API. It contains template classes that simplify the use of Web services, much like the JdbcTemplate does for JDBC. The design principle common to Spring template classes is to provide helper methods to perform common operations and for more sophisticated usage, delegate to user implemented callback interfaces. The Web service template follows the same design. The classes offer various convenience methods for the sending and receiving of XML - messages, marshalling objects to XML before sending, and allows for multiple transports, + messages, marshalling objects to XML before sending, and allows for multiple transport options.
@@ -60,7 +60,7 @@
- Sending and receiving a<interfacename>WebServiceMessage</interfacename> + <title>Sending and receiving a <interfacename>WebServiceMessage</interfacename> The WebServiceTemplate contains many convenience methods to send and receive @@ -136,7 +136,7 @@ public class WebServiceClient { WebServiceMessageCallback - To accommodate the setting of SOAP headers, and other settings on the message, the + To accommodate the setting of SOAP headers and other settings on the message, the WebServiceMessageCallback interface gives you access to the message after it has been created, but before it is sent. The example below demonstrates how to set the SOAP Action header on a message that is created by marshalling an object. diff --git a/src/docbkx/common.xml b/src/docbkx/common.xml index 34403f13..46a894c2 100644 --- a/src/docbkx/common.xml +++ b/src/docbkx/common.xml @@ -4,7 +4,7 @@ Shared components - In this chapter, we will explore the the components which are shared between client- and server side + In this chapter, we will explore the the components which are shared between client- and server-side Spring-WS development. These interfaces and classes represent the building blocks of Spring-WS, so it is important to understand what they do, even if you do not use them directly. @@ -13,14 +13,14 @@
<interfacename>WebServiceMessage</interfacename> - One of the core interfaces within Spring Web Services is the - WebServiceMessage. This interface represents a protocol agnostic XML - message. The interface contains methods that provide access to the payload of the message, in the form - of a javax.xml.transform.Source or a + One of the core interfaces of Spring Web Services is the WebServiceMessage. + This interface represents a protocol-agnostic XML message. The interface contains methods that provide + access to the payload of the message, in the form of a + javax.xml.transform.Source or a javax.xml.transform.Result. Source and Result are tagging interfaces that represent an abstraction over XML - input and output. Concrete implementations wrap various XML representations, as indicated in the table - below. + input and output. Concrete implementations wrap various XML representations, as indicated in the + following table. @@ -74,7 +74,7 @@
<interfacename>SoapMessage</interfacename> - The SoapMessage is an extension of + The SoapMessage is a subclass of WebServiceMessage. It contains SOAP-specific methods, such as getting SOAP Headers, SOAP Faults, etc. Generally, your code should not be dependent on SoapMessage, because the content of the SOAP Body can be obtained via @@ -87,12 +87,10 @@
Message Factories - Concrete message implementation are created by a - WebServiceMessageFactory. This factory can create an empty message, or - read a message based on an input stream. - There are two concrete implementations of WebServiceMessageFactory. - One is based on SAAJ, the SOAP with Attachments API for Java, the other based on Axis 2's AXIOM, the - AXis Object Model. + Concrete message implementations are created by a WebServiceMessageFactory. + This factory can create an empty message, or read a message based on an input stream. There are two + concrete implementations of WebServiceMessageFactory; one is based on + SAAJ, the SOAP with Attachments API for Java, the other based on Axis 2's AXIOM, the AXis Object Model.
<classname>SaajSoapMessageFactory</classname> @@ -101,13 +99,12 @@ create SoapMessage implementations. SAAJ is part of J2EE 1.4, so it should be supported under most modern application servers. You wire up a SaajSoapMessageFactory like so: - ]]> + ]]> SAAJ is based on DOM, the Document Object Model. This means that all SOAP messages are - stored in memory as a whole. For larger SOAP messages, this may not be very performant. + stored in memory. For larger SOAP messages, this may not be very performant. In that case, the AxiomSoapMessageFactory might be more applicable. @@ -260,7 +257,7 @@ public class MyXPathClass {
<classname>XPathTemplate</classname> - The XPathExpression only allows you to evaluate a single, pre-compiled + The XPathExpression allows you to evaluate only a single, pre-compiled expression. A more flexible, though slower, alternative is the XpathTemplate. This class follows the common template pattern used throughout Spring (JdbcTemplate, JmsTemplate, etc.). Here is an example: @@ -277,10 +274,6 @@ public class MyXPathClass { } }]]> - - Of course, the template could have been injected with a - constructor argument or a setter. -
\ No newline at end of file diff --git a/src/docbkx/oxm.xml b/src/docbkx/oxm.xml index c0f8cfa1..8868dbcc 100644 --- a/src/docbkx/oxm.xml +++ b/src/docbkx/oxm.xml @@ -165,9 +165,8 @@ public interface Unmarshaller { Even though there are two separate marshalling interfaces (Marshaller and Unmarshaller), all implementations found in Spring-WS implement both in - one class. This means that you can wire up one marshaller class and refer to it as marshaller and - unmarshaller in your applicationContext.xml - . + one class. This means that you can wire up one marshaller class and refer to it both as a marshaller and an + unmarshaller in your applicationContext.xml.
XmlMappingException @@ -317,7 +316,7 @@ public class Application { implementation of JAXB. Alternatively, JAXB2 offers a way to generate a schema from annotated Java classes. - Spring supports both the JAXB 1.0 as the JAXB 2.0 API as XML marshalling strategy, following the + Spring supports both the JAXB 1.0 and the JAXB 2.0 API as XML marshalling strategies, following the Marshaller and Unmarshaller interfaces described in . The corresponding integration classes reside in the org.springframework.oxm.jaxb package. @@ -330,7 +329,7 @@ public class Application { requires a context path to operate, which you can set using the contextPath property. The context path is a list of colon (:) separated Java package names that contain schema derived classes. The marshaller has an additional validating property which - defines whether to validate invoming XML. + defines whether to validate incoming XML. The next sample bean configuration shows how to configure a JaxbMarshaller @@ -423,26 +422,23 @@ public class Application {
XMLBeans - XMLBeans is an XML binding tool that has full XML Schema support, and offers full XML Infoset fidelity. It - takes a different approach that most other O/X mapping frameworks, in that all classes that are - generated from an XML Schema are all derived from XmlObject, and contain - XML binding information in them. + XMLBeans is an XML binding tool that has full XML Schema support, and offers full XML Infoset + fidelity. It takes a different approach to that of most other O/X mapping frameworks, in that + all classes that are generated from an XML Schema are all derived from + XmlObject, and contain XML binding information in them. For more information on XMLBeans, refer to the - XMLBeans web site . The Spring-WS integration classes reside in the - org.springframework.oxm.xmlbeans package. + XMLBeans web site . The Spring-WS integration classes reside + in the org.springframework.oxm.xmlbeans package.
XmlBeansMarshaller - The - XmlBeansMarshaller - implements both the - Marshaller - and - Unmarshaller - interface. It can be wired up as follows: + The XmlBeansMarshaller + implements both the Marshaller + and Unmarshaller + interfaces. It can be configured as follows: @@ -453,13 +449,9 @@ public class Application { ]]> - Note that the - XmlBeansMarshaller - can only marshal objects of type - XmlObject - , and not every - java.lang.Object - . + Note that the XmlBeansMarshaller + can only marshal objects of type XmlObject, + and not every java.lang.Object.
@@ -470,7 +462,7 @@ public class Application {
JiBX - The JiBX framework offers a solution similar to JDO does for ORM: a binding definition defines the + The JiBX framework offers a solution similar to that which JDO provides for ORM: a binding definition defines the rules for how your Java objects are converted to or from XML. After preparing the binding and compiling the classes, a JiBX binding compiler enhances the class files, and adds code to handle converting instances of the classes from or to XML. diff --git a/src/docbkx/security.xml b/src/docbkx/security.xml index 95b10dfa..6f63ba55 100644 --- a/src/docbkx/security.xml +++ b/src/docbkx/security.xml @@ -7,16 +7,15 @@
Introduction - In this chapter, we will show you how to add WS-Security aspects to your Web services. We will focus on the + This chapter explains how to add WS-Security aspects to your Web services. We will focus on the three different areas of WS-Security, namely: Authentication - This is the process of determining whether a - principal - is who they claim to be. In this context, a "principal" generally means a user, device or some other - system which can perform an action in your application. + This is the process of determining whether a principal is who they claim to be. + In this context, a "principal" generally means a user, device or some other system which can perform + an action in your application. @@ -47,8 +46,8 @@ Note that WS-Security (especially encryption and signing) requires substantial amounts of memory, and - will also decrease performance. If performance is important to you, you might want to consider using not - using WS-Security. + will also decrease performance. If performance is important to you, you might want to consider not using + WS-Security.
@@ -132,12 +131,12 @@
- Key stores + Keystores For most cryptographic operations, you will use standard java.security.KeyStore - objects. This includes certificate verification, message signing, signature verification, encryption, but + objects. This includes certificate verification, message signing, signature verification, and encryption, but excludes username and time-stamp verification. This section aims to give you some background knowledge on - key stores, and the Java tools that you can use to store keys and certificates in a key store file. This + keystores, and the Java tools that you can use to store keys and certificates in a keystore file. This information is mostly not related to Spring-WS, but to the general cryptographic features of Java. @@ -171,31 +170,30 @@
KeyTool - Supplied with your Java Virtual Machine is the keytool, a key and certificate - management utility. You can use this tool to create new key stores, add new private keys and + Supplied with your Java Virtual Machine is the keytool program, a key and certificate + management utility. You can use this tool to create new keystores, add new private keys and certificates to them, etc. It is beyond the scope of this document to provide a full reference of - the keytool command, but you can find a reference - here, or by giving the command keytool -help on - the command line. + the keytool command, but you can find a reference + here, + or by giving the command keytool -help on the command line.
KeyStoreFactoryBean - To easily load a key store using Spring configuration, you can use the + To easily load a keystore using Spring configuration, you can use the KeyStoreFactoryBean. It has a resource location property, which you can set to - point to the path of the key store to load. A password may be given to check the integrity of the - key store data. If a password is not given, integrity checking is not performed. + point to the path of the keystore to load. A password may be given to check the integrity of the + keystore data. If a password is not given, integrity checking is not performed. - ]]> - If you don't specify the location property, a new, empty key store will be created, which is most + If you don't specify the location property, a new, empty keystore will be created, which is most likely not what you want. @@ -203,8 +201,8 @@
KeyStoreCallbackHandler - To use the key stores within a XwsSecurityInterceptor, you will need to define a - KeyStoreCallbackHandler. This callback has three properties with type key store: + To use the keystores within a XwsSecurityInterceptor, you will need to define a + KeyStoreCallbackHandler. This callback has three properties with type keystore: (keyStore, trustStore, and symmetricStore). The exact stores used by the handler depend on the cryptographic operations that are to be performed by this handler. For private key operation, the @@ -216,7 +214,7 @@ Cryptographic operation - Key store used + Keystore used @@ -349,7 +347,7 @@ The simplest password validation handler is the SimplePasswordValidationCallbackHandler. This handler validates passwords - against a in-memory Properties object, which you can specify using the + against an in-memory Properties object, which you can specify using the users property, like so: good tutorial available. - The JaasPlainTextPasswordValidationCallbackHandler only requires a + The JaasPlainTextPasswordValidationCallbackHandler requires only a loginContextName to operate. It creates a new JAAS LoginContext using this name, and handles the standard JAAS NameCallback and PasswordCallback using the username @@ -440,12 +438,12 @@
Digest Username Authentication - When using password digests, the SOAP message also contain a UsernameToken element, + When using password digests, the SOAP message also contains a UsernameToken element, which itself contains a Username element and a Password element. - The difference is that the password is not sent as plain text, but as a digest.The + The difference is that the password is not sent as plain text, but as a digest. The recipient compares this digest to the digest he calculated from the known password of the user, and if - they are the same, the user is authenticated. It can be compared to the Digest - Authentication provided by HTTP servers. + they are the same, the user is authenticated. It can be compared to the Digest Authentication provided + by HTTP servers. To require that every incoming message contains a UsernameToken element with a @@ -483,7 +481,7 @@ The AcegiPlainTextPasswordValidationCallbackHandler requires an Acegi UserDetailService to operate. It uses this service to retrieve the password of the user specified in the token. The digest of the password contained in this details object is - then compared with the digest in the message. If they are equal, the user has succesfully + then compared with the digest in the message. If they are equal, the user has successfully authenticated, and a UsernamePasswordAuthenticationToken is stored in the SecurityContextHolder. You can set the service using the userDetailsService. Additionally, you can set a @@ -512,12 +510,11 @@ To make sure that all incoming SOAP messages carry a BinarySecurityToken, the security policy file should contain a RequireSignature element. This element can - carry further other elements, which will be covered in . - You can find a reference of possible child elements - here. + further carry other elements, which will be covered in . + You can find a reference of possible child elements + here. - ... @@ -532,7 +529,7 @@ In most cases, certificate authentication should be preceded by certificate - validation, since you only want authenticate against valid certificates. + validation, since you only want to authenticate against valid certificates. Invalid certificates such as certificates for which the expiration date has passed, or which are not in your store of trusted certificates, should be ignored. @@ -562,7 +559,7 @@
KeyStoreCallbackHandler - The KeyStoreCallbackHandler uses a standard Java key store to validate + The KeyStoreCallbackHandler uses a standard Java keystore to validate certificates. This certificate validation process consists of the following steps: @@ -573,7 +570,7 @@ - If the certificate is not in the private key store, the handler will check whether the + If the certificate is not in the private keystore, the handler will check whether the the current date and time are within the validity period given in the certificate. If they are not, the certificate is invalid; if it is, it will continue with the final step. @@ -583,16 +580,16 @@ Finally, a certification path for the certificate is created. This basically means that the handler will determine whether the certificate has been issued - by any of the certificate authorities in the trustStore. If it - a certification path can be built succesfully, the certificate is valid. Otherwise, it - is not. + by any of the certificate authorities in the trustStore. If + a certification path can be built successfully, the certificate is valid. Otherwise, + the certificate is not. To use the KeyStoreCallbackHandler for certificate validation purposes, you - will most likely only set the trustStore property: + will most likely set only the trustStore property: @@ -612,10 +609,10 @@ AcegiCertificateValidationCallbackHandler The AcegiCertificateValidationCallbackHandler requires an Acegi - AuthenticationManager to operate. It uses this manager authenticate against a + AuthenticationManager to operate. It uses this manager to authenticate against a X509AuthenticationToken that it creates. The configured authentication manager is expected to supply a provider which can handle this token (usually an instance of - X509AuthenticationProvider). If authentication is succesfull, the token is + X509AuthenticationProvider). If authentication is succesful, the token is stored in the SecurityContextHolder. You can set the authentication manager using the authenticationManager property: @@ -800,7 +797,7 @@ To decrypt incoming SOAP messages, the security policy file should contain a RequireEncryption element. This element can further carry a EncryptionTarget element which indicates which part of the message should be - encrypted, a SymmetricKey to indicate that a shared secret instead of the regular + encrypted, and a SymmetricKey to indicate that a shared secret instead of the regular private key should be used to decrypt the message. You can read a description of the other elements here. @@ -846,7 +843,7 @@ To encrypt outgoing SOAP messages, the security policy file should contain a Encrypt element. This element can further carry a EncryptionTarget element which indicates - which part of the message should be encrypted, a SymmetricKey to indicate that a + which part of the message should be encrypted, and a SymmetricKey to indicate that a shared secret instead of the regular private key should be used to decrypt the message. You can read a description of the other elements diff --git a/src/docbkx/server.xml b/src/docbkx/server.xml index ffae9ca7..5b8a5ece 100644 --- a/src/docbkx/server.xml +++ b/src/docbkx/server.xml @@ -10,7 +10,7 @@ MessageDispatcher that dispatches incoming messages to endpoints, with configurable endpoint mappings, response generation, and endpoint interception. - The simplest endpoint is a PayloadEndpoint, just offering a + The simplest endpoint is a PayloadEndpoint, which just offers the Source invoke(Source request) method. You are of course free to implement this interface directly, but you will probably prefer to extend one of the included abstract implementations such as @@ -86,7 +86,7 @@ Exceptions that are thrown during handling of the request get picked up by any of the endpoint exception resolvers that are declared in the application context. Using these exception resolvers allows you to define - custom behaviors in case such exceptions get thrown, such as return a SOAP Fault. + custom behaviors (such as returning a SOAP Fault) in case such exceptions get thrown. The MessageDispatcher has several properties, for setting endpoint adapters, @@ -184,8 +184,8 @@ Alternatively, there is the MessageEndpoint, which operates on a whole MessageContext rather than just - the payload. Typically, your code should only not be dependent on messages, because the payload should - contain the interesting information. Only when it is necessary to perform actions on the mesage as a whole, + the payload. Typically, your code should not be dependent on messages, because the payload should + contain the information of interest. Only when it is necessary to perform actions on the message as a whole, such as adding a SOAP header, get an attachment, and so forth, should you need to implement MessageEndpoint, though these actions are usually performed in a endpoint interceptor. @@ -195,11 +195,11 @@ One of the most basic ways to handle the incoming XML payload is by using a DOM (Document Object Model) API. By extending from AbstractDomPayloadEndpoint, you can use the - org.w3c.dom.Element and related classes to handle the request, and create the + org.w3c.dom.Element and related classes to handle the request and create the response. When using the AbstractDomPayloadEndpoint as the baseclass for your endpoints you only have to override the invokeInternal(Element, Document) - method, implement your logic, and return an Element if you want a - response. Here is a short example consisting of a class and a declaration in the application context. + method, implement your logic, and return an Element if a response is + necessary. Here is a short example consisting of a class and a declaration in the application context. ]]> - The above class and the declaration in the application context is all you need besides setting up an + The above class and the declaration in the application context are all you need besides setting up an endpoint mapping (see the section entitled ) to get this very simple endpoint working. The SOAP message handled by this endpoint will look something like: @@ -245,7 +245,7 @@ public class SampleEndpoint extends AbstractDomPayloadEndpoint { Hello ]]> - The SOAP reponse looks like: + The SOAP response looks like: ]]>invokeInternal method, we cast the request object to an OrderRequest object, which is the JAXB object representing the payload of the - request. Using the identifier of that request, we obtain an order from our business service, which we - returned. The returned object is marshalled into XML, and used as the payload of the response message. + request. Using the identifier of that request, we obtain an order from our business service and return + it. The returned object is marshalled into XML, and used as the payload of the response message. The SOAP request handled by this endpoint will look like: @@ -366,10 +366,10 @@ public class MarshallingOrderEndpoint extends AbstractMarshallingPayloadEndpoint
<interfacename>@Endpoint</interfacename> - The previous two programming models were based on inheritance, and handled individual XML mesages. - Spring Web Services offer another endpoint with which you aggregate multiple handling into one - controller, thus grouping functionality together. This model is based on annotations, so you can only - use it under Java 5 and higher. Here is an example that uses the same marshalled objects as above: + The previous two programming models were based on inheritance, and handled individual XML messages. + Spring Web Services offer another endpoint with which you can aggregate multiple handling into one + controller, thus grouping functionality together. This model is based on annotations, so you can use + it only with Java 5 and higher. Here is an example that uses the same marshalled objects as above: // create Source from order and return it @@ -517,9 +517,9 @@ public class AnnotationOrderEndpoint { EndpointMapping. - A EndpointMapping delivers a EndpointInvocationChain, + An EndpointMapping delivers a EndpointInvocationChain, which contains the endpoint that matches the incoming request, and may also contain a list of endpoint - interceptors that are applied to the request and response. When a request comes in, the + interceptors that will be applied to the request and response. When a request comes in, the MessageDispatcher will hand it over to the endpoint mapping to let it inspect the request and come up with an appropriate EndpointInvocationChain. Then the MessageDispatcher will invoke the endpoint and any interceptors in the chain. @@ -528,7 +528,8 @@ public class AnnotationOrderEndpoint { The concept of configurable endpoint mappings that can optionally contain interceptors (which can manipulate the request or the response, or both) is extremely powerful. A lot of supporting functionality can be built into custom EndpointMappings. For example, there could be a custom endpoint mapping that - chooses an endpoint not only based on the contents of a message, but also a specific SOAP headers. + chooses an endpoint not only based on the contents of a message, but also on a specific SOAP header(or + indeed multiple SOAP headers). Most endpoint mappings inherit from the AbstractEndpointMapping, which offers an @@ -581,7 +582,7 @@ public class AnnotationOrderEndpoint { PayloadRootQNameEndpointMapping, you can use the SOAPAction HTTP header to route messages. Every client sends this header when making a SOAP request, and the header value used for a request is defined in the WSDL. By making the SOAPAction - unique per operation, you can use it a a discriminator. Here is an example: + unique per operation, you can use it as a discriminator. Here is an example: @@ -602,10 +603,10 @@ public class AnnotationOrderEndpoint { ]]> - The mapping above routes requests which have the a SOAPAction of + The mapping above routes requests which have a SOAPAction of http://samples/RequestOrder to the 'getOrderEndpoint'. Requests with http://samples/CreateOrder will be routed to the 'createController'. - Note that using SOAP Action headers is SOAP-specific, so it cannot be used when using Plain Old XML. + Note that using SOAP Action headers is SOAP-specific, so it cannot be used with Plain Old XML messages.
@@ -639,15 +640,15 @@ public class AnnotationOrderEndpoint {
Intecepting requests - the <interfacename>EndpointInterceptor</interfacename> interface - The endpoint mapping mechanism has the notion of endpoint interceptors, that can be extremely useful + The endpoint mapping mechanism has the notion of endpoint interceptors. These can be extremely useful when you want to apply specific functionality to certain requests, for example, dealing with - security-related SOAP headers, or logging the request and response message. + security-related SOAP headers, or the logging of request and response message. - Interceptors located in the endpoint mapping must implement - EndpointInterceptor from the + Interceptors located in the endpoint mapping must implement the + EndpointInterceptor interface from the org.springframework.ws.server package. This interface defines three methods, one that - can be used for handling the request message has been determined before the actual + can be used for handling the request message before the actual endpoint will be executed, one that can be used for handling a normal response message, and one that can be used for handling fault messages, both of which will be called after the endpoint is executed. These three methods should provide enough flexibility to do all kinds of @@ -659,7 +660,7 @@ public class AnnotationOrderEndpoint { returns true, the endpoint execution chain will continue, when it returns false, the MessageDispatcher interprets this to mean that the interceptor itself - has taken care of things and does not continue executing the other interceptors and the actual endoint + has taken care of things and does not continue executing the other interceptors and the actual endpoint in the invocation chain. The handleResponse(..) and handleFault(..) methods also have a boolean return value. When these methods return false, the response will not be sent back to the client. @@ -676,8 +677,8 @@ public class AnnotationOrderEndpoint { When developing a Web service, it can be useful to log the incoming and outgoing XML messages to the log. Spring Web Services facilitates this with the PayloadLoggingInterceptor and the - SoapEnvelopeLoggingInterceptor. The former just logs the payload of the - message to the Commons Logging Log; the latter logs the entire SOAP Envelope, including SOAP + SoapEnvelopeLoggingInterceptor. The former logs just the payload of the + message to the Commons Logging Log; the latter logs the entire SOAP envelope, including SOAP headers. This example shows you how to define them in an endpoint mapping: @@ -756,7 +757,7 @@ public class AnnotationOrderEndpoint { response messages using /WEB-INF/oldResponses.xslt. Note that, since endpoint interceptors are registered at the endpoint mapping level, you can simply create a endpoint mapping that applies to the "old style" messages, and add the interceptor to that mapping. - Hence, the transformation will only apply to these "old style" message. + Hence, the transformation will apply only to these "old style" message.
@@ -769,23 +770,21 @@ public class AnnotationOrderEndpoint { Endpoint exception resolvers somewhat resemble the exception mappings that can be defined in the web application descriptor web.xml. However, they provide a more flexible way to handle exceptions. They provide information about what - endpoint was invoked when the exception was thrown. - Furthermore, a programmatic way of handling exceptions gives you many more options for how to respond - appropriately. - Finally, rather than expose the innards of your application by giving an exception and stack trace, you - can handle the exception any way you want, for example return a SOAP fault with a specific fault code and string. + endpoint was invoked when the exception was thrown. Furthermore, a programmatic way of handling exceptions + gives you many more options for how to respond appropriately. Rather than expose the innards of your + application by giving an exception and stack trace, you can handle the exception any way you want, for + example by returning a SOAP fault with a specific fault code and string. - Endpoint exception resolvers are automatically picked up by the MessageDispatcher, so - you don't have to configure them explicitly. + Endpoint exception resolvers are automatically picked up by the MessageDispatcher, + so no explicit configuration is necessary. Besides implementing the EndpointExceptionResolver interface, which is only a matter of implementing the resolveException(MessageContext, endpoint, Exception) method, you may also use one of the default implementations. - The simplest implementation is the SimpleSoapExceptionResolver, which simply - always creates a SOAP 1.1 Server or SOAP 1.2 Receiver Fault, and uses the exception message as the fault - string. + The simplest implementation is the SimpleSoapExceptionResolver, which just + creates a SOAP 1.1 Server or SOAP 1.2 Receiver Fault, and uses the exception message as the fault string. A more sophisticated implementation is the SoapFaultMappingExceptionResolver. @@ -808,11 +807,10 @@ public class AnnotationOrderEndpoint { ]]> The key values and default endpoint use the format faultCode,faultString,locale, where - only the fault code is required. - If the fault string is not set, it will default to the exception message. - If the language is not set, it will default to English. - The configuration above will map exceptions of type ValidationFailureException - to a sender side SOAP Fault with a fault string "Invalid request": + only the fault code is required. If the fault string is not set, it will default to the exception message. + If the language is not set, it will default to English. The above configuration will map exceptions of + type ValidationFailureException to a client-side SOAP Fault with a fault string + "Invalid request", as can be seen in the following response: ]]> ]]> - If any other exception occurs, it will return the default fault: a server side fault with the exception + If any other exception occurs, it will return the default fault: a server-side fault with the exception message as fault string. - - - Finally, it is possible to annotate exception classes with the @SoapFault + Finally, it is also possible to annotate exception classes with the @SoapFault annotation, to indicate the SOAP Fault that should be returned whenever that exception is thrown. The elements of the annotation include a fault code enumeration, fault string or reason, and language. Here is an example exception: @@ -845,9 +841,8 @@ public class MyBusinessException extends Exception { } }]]> - Whever the MyBusinessException is thrown with the constructor string - Oops! during endpoint invocation, it will result in - the following response: + Whenever the MyBusinessException is thrown with the constructor string + "Oops!" during endpoint invocation, it will result in the following response: