From 1972a839a42b60c0b586c26ed0bf3c3f252671bf Mon Sep 17 00:00:00 2001 From: Kirill Gavrilov Date: Tue, 1 Dec 2020 15:41:13 -0600 Subject: [PATCH] Fix typo in why-contract-first.adoc. Resolves #152. --- src/main/asciidoctor/why-contract-first.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/main/asciidoctor/why-contract-first.adoc b/src/main/asciidoctor/why-contract-first.adoc index 6e78e601..e999dc04 100644 --- a/src/main/asciidoctor/why-contract-first.adoc +++ b/src/main/asciidoctor/why-contract-first.adoc @@ -153,7 +153,7 @@ Besides the Object/XML Mapping issues mentioned in the previous section, there a As mentioned earlier, the contract-last development style results in your web service contract (WSDL and your XSD) being generated from your Java contract (usually an interface). If you use this approach, you have no guarantee that the contract stays constant over time. Each time you change your Java contract and redeploy it, there might be subsequent changes to the web service contract. -Aditionally, not all SOAP stacks generate the same web service contract from a Java contract. This means that changing your current SOAP stack for a different one (for whatever reason) might also change your web service contract. +Additionally, not all SOAP stacks generate the same web service contract from a Java contract. This means that changing your current SOAP stack for a different one (for whatever reason) might also change your web service contract. When a web service contract changes, users of the contract have to be instructed to obtain the new contract and potentially change their code to accommodate for any changes in the contract.