diff --git a/docs/src/main/docbook/async.xml b/docs/src/main/docbook/async.xml
index 824f095..6d7d082 100644
--- a/docs/src/main/docbook/async.xml
+++ b/docs/src/main/docbook/async.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2012, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -224,7 +224,7 @@
                 multiple callbacks using varags.
             </para>
             <para>
-                As some async requests may take long time to process the client may decide to terminate it's connection to the
+                As some async requests may take long time to process the client may decide to terminate its connection to the
                 server before the response has been resumed or before it has been fully written to the client. To deal with these
                 use cases a &lit.jaxrs.container.ConnectionCallback; can be used. This callback will be executed only if the
                 connection was prematurely terminated or lost while the response is being written to the back client. Note that
diff --git a/docs/src/main/docbook/bean-validation.xml b/docs/src/main/docbook/bean-validation.xml
index 2436d92..e12fe3c 100644
--- a/docs/src/main/docbook/bean-validation.xml
+++ b/docs/src/main/docbook/bean-validation.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2013, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2013, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -84,8 +84,8 @@
 
         <para>
             As stated in <xref linkend="deployment.autodiscoverable"/>, Jersey Bean Validation is one of the modules where you
-            don't need to explicitly register it's &lit.jaxrs.core.Feature;s (&jersey.ext.ValidationFeature;) on the
-            server as it's features are automatically discovered and registered when you add the
+            don't need to explicitly register its &lit.jaxrs.core.Feature;s (&jersey.ext.ValidationFeature;) on the
+            server as its features are automatically discovered and registered when you add the
             &lit.jersey-bean-validation; module to your classpath.
             There are three Jersey specific properties that could disable automatic discovery and registration of Jersey Bean
             Validation integration module:
diff --git a/docs/src/main/docbook/client.xml b/docs/src/main/docbook/client.xml
index 4a8d6a8..90964a3 100644
--- a/docs/src/main/docbook/client.xml
+++ b/docs/src/main/docbook/client.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2010, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2010, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -233,7 +233,7 @@
             </title>
 
             <para>
-                JAX-RS Client API is a designed to allow fluent programming model. This means, a construction of a
+                JAX-RS Client API is designed to allow fluent programming model. This means, a construction of a
                 &lit.jaxrs.client.Client; instance, from which a &lit.jaxrs.client.WebTarget; is created, from which a
                 request &jaxrs.client.Invocation; is built and invoked can be chained in a single "flow" of invocations.
                 The individual steps of the flow will be shown in the following sections.
@@ -345,7 +345,7 @@
 webTarget.register(FilterForExampleCom.class);</programlisting>
 
                 The configuration principles used in JAX-RS client API apply to &lit.jaxrs.client.WebTarget; as well. Each
-                &lit.jaxrs.client.WebTarget; instance inherits a configuration from it's parent (either a client or another
+                &lit.jaxrs.client.WebTarget; instance inherits a configuration from its parent (either a client or another
                 web target) and can be further custom-configured without affecting the configuration of the parent component.
                 In this case, the <literal>FilterForExampleCom</literal> will be registered only in the
                 <literal>webTarget</literal> and not in <literal>client</literal>. So, the <literal>client</literal>
@@ -739,7 +739,7 @@
 clientConfig.connectorProvider(new GrizzlyConnectorProvider());
 Client client = ClientBuilder.newClient(clientConfig);</programlisting>
 
-            &lit.jaxrs.client.Client; accepts as as a constructor argument a &lit.jaxrs.core.Configurable; instance. Jersey
+            &lit.jaxrs.client.Client; accepts as a constructor argument a &lit.jaxrs.core.Configurable; instance. Jersey
             implementation of the &lit.jaxrs.core.Configurable; provider for the client is &lit.jersey.client.ClientConfig;.
             By using the Jersey &lit.jersey.client.ClientConfig; you can configure the custom
             &lit.jersey.client.ConnectorProvider;
@@ -965,7 +965,7 @@
                         <emphasis>UNIVERSAL:</emphasis> Combination of basic and digest authentication. The feature works in non-preemptive
                           mode which means that it sends requests without authentication information. If <literal>401</literal> status
                           code is returned, the request is repeated and an appropriate authentication is used based on the
-                          authentication requested in the response (defined in <literal>WWW-Authenticate</literal> HTTP header. The feature
+                          authentication requested in the response (defined in <literal>WWW-Authenticate</literal> HTTP header). The feature
                           remembers which authentication requests were successful for given URI and next time tries to preemptively
                           authenticate against this URI with latest successful authentication method.
                     </para>
diff --git a/docs/src/main/docbook/custom-di.xml b/docs/src/main/docbook/custom-di.xml
index a6bc2d2..4229553 100644
--- a/docs/src/main/docbook/custom-di.xml
+++ b/docs/src/main/docbook/custom-di.xml
@@ -37,7 +37,7 @@
     </para>
 
     <para>
-        Jersey user guide can by no means supply an exhaustive documentation of HK2 API in it's entire scope.
+        Jersey user guide can by no means supply an exhaustive documentation of HK2 API in its entire scope.
         This chapter only points out the most common scenarios related
         to dependency injection in Jersey and suggests possible options to implement these scenarios.
         It is highly recommended to check out the &hk2.link; website and read HK2 documentation in order to get
@@ -65,8 +65,8 @@
         as a good example that will help me demonstrate implementation of the use cases described above.
         The following examples should work on top of Jersey Servlet integration module. The approach that will be
         demonstrated could be further generalized.
-        Bellow i will show how to make actual Servlet &jee6.servlet.HttpSession; injectable into JAX-RS components
-        and how to make this injection work with a custom inject annotation type. Finally, i will demonstrate
+        Below we will show how to make actual Servlet &jee6.servlet.HttpSession; injectable into JAX-RS components
+        and how to make this injection work with a custom inject annotation type. Finally, we will demonstrate
         how you can write &lit.jee6.servlet.HttpSession;-scoped JAX-RS resources.
     </para>
 
@@ -487,7 +487,7 @@
             The first and very important aspect of writing your own &lit.jersey.server.spi.ComponentProvider;
             in Jersey is to store the actual HK2 &hk2.ServiceLocator; instance that will be passed to you as
             the only argument of the provider <literal>initialize</literal> method.
-            Your component provider instance will not get injected at all so this is more less your only chance
+            Your component provider instance will not get injected at all so this is more or less your only chance
             to get access to the HK2 runtime of your application. Please bear in mind, that at the time when
             your component provider methods get invoked, the &lit.hk2.ServiceLocator; is not fully configured yet.
             This limitation applies to all component provider methods, as the main goal of any component provider
@@ -513,7 +513,7 @@
         </para>
 
         <para>
-            The implementation of the <literal>PerSessionFactory</literal> is is also included above.
+            The implementation of the <literal>PerSessionFactory</literal> is also included above.
             Please note that as opposed to a component provider implementation that should never itself rely
             on an injection support, the factory bound by our component provider would get injected just fine,
             since it is only instantiated later, once the Jersey runtime for the application is fully
diff --git a/docs/src/main/docbook/declarative-linking.xml b/docs/src/main/docbook/declarative-linking.xml
index 0f4286c..54786c5 100644
--- a/docs/src/main/docbook/declarative-linking.xml
+++ b/docs/src/main/docbook/declarative-linking.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!--
 
-    Copyright (c) 2010, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2010, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -98,7 +98,7 @@
 }</programlisting>
 
         <para>
-            After a call to<literal>WidgetsResource#get</literal>, the Jersey runtime will inject the value
+            After a call to <literal>WidgetsResource#get</literal>, the Jersey runtime will inject the value
             <literal>"/context/widgets"</literal>
             <footnote>
                 <para>
@@ -143,7 +143,7 @@
         <para>
             The <literal>@ProvideLink</literal> annotation can be repeated to add links to different entities using different
             options. Entities are defined via the <literal>value</literal> property. If the entities are similar in structure they
-            can also declared as an array. <literal>@ProvideLink</literal> also works with class hierarchies, e.g., contributions
+            can also be declared as an array. <literal>@ProvideLink</literal> also works with class hierarchies, e.g., contributions
             defined for a superclass will also be injected into the derived classes (interfaces are not supported).
 
             <programlisting language="java">@ProvideLink(value = Order.class,rel = "self",
diff --git a/docs/src/main/docbook/deployment.xml b/docs/src/main/docbook/deployment.xml
index 062b454..9318428 100644
--- a/docs/src/main/docbook/deployment.xml
+++ b/docs/src/main/docbook/deployment.xml
@@ -73,7 +73,7 @@
         <para>
             Compared to &lit.jaxrs.core.Application;, the &lit.jersey.server.ResourceConfig; provides advanced capabilities
             to simplify registration of JAX-RS components, such as scanning for root resource and provider classes in a provided
-            classpath or a in a set of package names etc. All JAX-RS component classes that are either manually registered or
+            classpath or a set of package names etc. All JAX-RS component classes that are either manually registered or
             found during scanning are automatically added to the set of classes that are returned by
             <literal>getClasses</literal>. For example, the following application class that extends from
             &lit.jersey.server.ResourceConfig; scans during deployment for JAX-RS components in packages
@@ -1101,7 +1101,7 @@
                 <para>
                     As explained in <link linkend="servlet-app-glassfish">2.3.1</link> , you don't need to add any specific
                     dependencies on GlassFish, Jersey is already packaged within GlassFish. You only need to add the
-                    <literal>provided</literal>-scoped dependencies to you project to be able to compile it. At runtime,
+                    <literal>provided</literal>-scoped dependencies to your project to be able to compile it. At runtime,
                     GlassFish will make sure that your application has access to the Jersey libraries.
                 </para>
 
diff --git a/docs/src/main/docbook/entity-filtering.xml b/docs/src/main/docbook/entity-filtering.xml
index 0acc5e0..7bf2570 100644
--- a/docs/src/main/docbook/entity-filtering.xml
+++ b/docs/src/main/docbook/entity-filtering.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2013, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2013, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -217,7 +217,7 @@
 
         <para>
             In the next section the entity-filtering features will be illustrated on a project-tracking application that
-            contains three classes in it's domain model and few resources (only <literal>Project</literal> resource will be
+            contains three classes in its domain model and few resources (only <literal>Project</literal> resource will be
             shown in this chapter). The full source code for the example application can be found in Jersey
             &jersey.github.ef.example.link;.
         </para>
@@ -493,9 +493,9 @@
             to all the child nodes. Fields and child nodes that do not match at least a single active scope are filtered out.
             When the scope matching is performed, annotations applied to the domain model classes and fields
             are used to compute the scope for each particular component of the model. If there are no annotations on the class
-            or it's fields, the default scope is assumed. During the filtering, first, the annotations on root model class
-            and it's fields are considered. For all composite fields that have not been filtered out, the annotations on the
-            referenced child class and it's fields are considered next, and so on.
+            or its fields, the default scope is assumed. During the filtering, first, the annotations on root model class
+            and its fields are considered. For all composite fields that have not been filtered out, the annotations on the
+            referenced child class and its fields are considered next, and so on.
         </para>
 
         <section>
@@ -625,7 +625,7 @@
             <para>
                 As mentioned above you can define applied entity-filtering scopes using a property set either in the client
                 run-time &lit.jaxrs.core.Configuration; (see <xref linkend="ef.example.client.registration"/>) or by
-                passing the entity-filtering annotations during a creation of an individual request to be sent to server.
+                passing the entity-filtering annotations during a creation of an individual request to be sent to the server.
 
                 <example>
                     <title>Client - Request entity-filtering annotations</title>
@@ -764,7 +764,7 @@
             <itemizedlist>
                 <listitem>
                     <para>&jersey.message.filtering.EntityProcessor;</para>
-                    <para>Implementations of this SPI are invoked to process entity class and it's members. Custom
+                    <para>Implementations of this SPI are invoked to process entity class and its members. Custom
                         implementations can extend from &jersey.message.filtering.AbstractEntityProcessor;.</para>
                 </listitem>
                 <listitem>
diff --git a/docs/src/main/docbook/filters.xml b/docs/src/main/docbook/filters.xml
index fa2ec6f..ec25557 100644
--- a/docs/src/main/docbook/filters.xml
+++ b/docs/src/main/docbook/filters.xml
@@ -513,7 +513,7 @@
             it is annotated with &lit.jaxrs.NameBinding;. The <literal>@Compress</literal> is applied on the
             resource method <literal>getVeryLongString()</literal> and on the interceptor
             <literal>GZIPWriterInterceptor</literal>. The interceptor will be executed only if any resource method
-            with such a annotation will be executed. In our example case the interceptor will be executed only for
+            with such an annotation will be executed. In our example case the interceptor will be executed only for
             the <literal>getVeryLongString()</literal> method. The interceptor will not be executed for method
             <literal>getHello()</literal>. In this example the reason is probably clear. We would like to compress
             only long data and we do not need to compress the short response of "Hello World!".
@@ -536,7 +536,7 @@
             just an edge case which will not be used so often.
         </para>
         <para>
-            Note that <emphasis>global filters are executed always</emphasis>, so even for resource methods
+            Note that <emphasis>global filters are always executed</emphasis>, even for resource methods
             which have any name binding annotations.
         </para>
     </section>
@@ -638,7 +638,7 @@
         <para>
             It's a good practice to assign a priority to filters and interceptors. Use &jaxrs.Priorities; class which
             defines standardized priorities in JAX-RS for different usages, rather than inventing your
-            own priorities. So, when you for example write an authentication filter you would assign a priority 1000 which
+            own priorities. For example, when you write an authentication filter you would assign a priority 1000 which
             is the value of &lit.jaxrs.Priorities;<literal>.AUTHENTICATION</literal>. The following example
             shows the filter from the beginning
             of this chapter with a priority assigned.
diff --git a/docs/src/main/docbook/getting-started.xml b/docs/src/main/docbook/getting-started.xml
index e2c9300..fdb64a8 100644
--- a/docs/src/main/docbook/getting-started.xml
+++ b/docs/src/main/docbook/getting-started.xml
@@ -176,7 +176,7 @@
 
             In this unit test, a Grizzly container is first started and server application is deployed in the
             test <literal>setUp()</literal> method by a static call to <literal>Main.startServer()</literal>.
-            Next, a JAX-RS client components are created in the same test set-up method. First a new JAX-RS client
+            Next, JAX-RS client components are created in the same test set-up method. First a new JAX-RS client
             instance <literal>c</literal> is built and then a JAX-RS web target component pointing to the context root of our
             application deployed at <literal>http://localhost:8080/myapp/</literal> (a value of
             <literal>Main.BASE_URI</literal> constant) is stored into a <literal>target</literal> field of the unit test class.
diff --git a/docs/src/main/docbook/jaxrs-resources.xml b/docs/src/main/docbook/jaxrs-resources.xml
index 9ec514f..5f73ad4 100644
--- a/docs/src/main/docbook/jaxrs-resources.xml
+++ b/docs/src/main/docbook/jaxrs-resources.xml
@@ -612,7 +612,7 @@
         <para>If the path of the request URL is "printers" then the resource methods not annotated with &jaxrs.Path;
             will be selected. If the request path of the request URL is "printers/list" then first the root resource class
             will be matched and then the sub-resource methods that match "list" will be selected, which in this case
-            is the sub-resource method<literal>getListOfPrinters</literal>. So, in this example hierarchical matching
+            is the sub-resource method <literal>getListOfPrinters</literal>. So, in this example hierarchical matching
             on the path of the request URL is performed.
         </para>
 
diff --git a/docs/src/main/docbook/mbw.xml b/docs/src/main/docbook/mbw.xml
index cff05c4..b61881b 100644
--- a/docs/src/main/docbook/mbw.xml
+++ b/docs/src/main/docbook/mbw.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2012, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -416,7 +416,7 @@
                     <literal>@Consumes("application/xml")</literal>,
                     therefore for purpose of de-serialization of entity for the <literal>postMyBean()</literal> method,
                     only requests with entities represented as <literal>"application/xml"</literal>
-                    media type will match the method. However, this method might be executed for for entity types that are sub classes
+                    media type will match the method. However, this method might be executed for entity types that are sub classes
                     or super classes of the declared generic type on the &lit.jaxrs.ext.MessageBodyReader; will be also considered.
                     It is a responsibility of the <literal>isReadable</literal> method to decide whether it is able
                     to de-serialize the entity and type comparison is one of the basic decision steps.
@@ -592,7 +592,7 @@
                     Determine the media type of the response.
                 </para>
                 <para>
-                    In our case. for resource method <literal>getMyBean</literal>
+                    In our case, for resource method <literal>getMyBean</literal>
                     annotated with <literal>@Produces("application/xml")</literal>, the media type will be
                     <literal>"application/xml"</literal>.
                 </para>
@@ -649,7 +649,7 @@
                 <stepalternatives>
                     <step>
                         <para>
-                            Otherwise, the server runtime MUST generate a generate an
+                            Otherwise, the server runtime MUST generate an
                             <literal>InternalServerErrorException</literal>, a subclass of
                             <literal>WebApplicationException</literal> with its status set to 500, and no entity and the client
                             runtime MUST generate a <literal>ProcessingException</literal>.
diff --git a/docs/src/main/docbook/media.xml b/docs/src/main/docbook/media.xml
index e0dca33..301c6c2 100644
--- a/docs/src/main/docbook/media.xml
+++ b/docs/src/main/docbook/media.xml
@@ -267,7 +267,7 @@
 
                 <para>
                     As stated in the <xref linkend="deployment.autodiscoverable"/> as well as earlier in this chapter, MOXy media
-                    module is one of the modules where you don't need to explicitly register it's &lit.jaxrs.core.Feature;s
+                    module is one of the modules where you don't need to explicitly register its &lit.jaxrs.core.Feature;s
                     (&lit.jersey.media.MoxyJsonFeature;) in your client/server &jaxrs.core.Configurable; as this feature is
                     automatically discovered and registered when you add &lit.jersey-media-moxy; module to your class-path.
                 </para>
@@ -458,7 +458,7 @@
 
                 <para>
                     As stated in <xref linkend="deployment.autodiscoverable"/> JSON-Processing media module is one of the
-                    modules where you don't need to explicitly register it's
+                    modules where you don't need to explicitly register its
                     &lit.jaxrs.core.Feature;s (&lit.jersey.media.JsonProcessingFeature;) in your client/server
                     &jaxrs.core.Configurable; as this feature is automatically discovered and registered when you add
                     &lit.jersey-media-json-processing; module to your classpath.
@@ -1507,7 +1507,7 @@
             <title>Client</title>
 
             <para>
-                &jersey.media.multipart.MultiPart; class (or it's subclasses) can be used as an entry point to using
+                &jersey.media.multipart.MultiPart; class (or it's subclasses) can be used as an entry point to use
                 &lit.jersey-media-multipart; module on the client side. This class represents a
                 <link xlink:href='&wikipedia.uri;MIME#Multipart_messages'>MIME multipart message</link> and is able
                 to hold an arbitrary number of &jersey.media.multipart.BodyPart;s. Default media type is
@@ -1696,7 +1696,7 @@
                             <para>
                                 A <literal>List</literal> or <literal>Collection</literal> of
                                 &lit.jersey.media.multipart.FormDataBodyPart;.
-                                The value of the parameter will one or more named body parts with the same name or
+                                The value of the parameter will be one or more named body parts with the same name or
                                 &lit.null; if such a named body part is not present.
                             </para>
                         </listitem>
@@ -1711,7 +1711,7 @@
                             <para>
                                 A <literal>List</literal> or <literal>Collection</literal> of
                                 &lit.jersey.media.multipart.FormDataContentDisposition;.
-                                The value of the parameter will one or more content dispositions of the named body parts with the
+                                The value of the parameter will be one or more content dispositions of the named body parts with the
                                 same name or &lit.null; if such a named body part is not present.
                             </para>
                         </listitem>
diff --git a/docs/src/main/docbook/migration.xml b/docs/src/main/docbook/migration.xml
index b502ce7..c639909 100644
--- a/docs/src/main/docbook/migration.xml
+++ b/docs/src/main/docbook/migration.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2012, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -40,7 +40,7 @@
                             module) are now being built with Java SE 8 and with 1.8 language level.
                         </para>
                         <para>
-                            As a consequential change, one of the modules was dropped, the<literal>rx-client-jsr166e</literal>.
+                            As a consequential change, one of the modules was dropped, the <literal>rx-client-jsr166e</literal>.
                             This implementation relied on the
                             <literal>ConcurrentHashMapV8</literal>
                             and was made redundant by the JDK upgrade. Please use
@@ -52,7 +52,7 @@
                             of Java 8 support with Spring 3.x versions.
                         </para>
                         <para>
-                            Jersey proprietary reactive client API has beed dropped and replaced by JAX-RS 2.1 Reactive Client API.
+                            Jersey proprietary reactive client API has been dropped and replaced by JAX-RS 2.1 Reactive Client API.
                             The backwards compatibility rule couldn't be respected in this case, since the JAX-RS API are based on
                             what was done in Jersey and there were unresolvable code incompatibilities.
                         </para>
@@ -217,11 +217,11 @@
                             http header, the URI was resolved against
                             <emphasis>base uri</emphasis>
                             of the application. This behaviour was not correct, as pointed out by &jersey.jira.2883;. With this
-                            change, the URI is, by default, resolved against<emphasis>request base uri</emphasis>.
+                            change, the URI is, by default, resolved against <emphasis>request base uri</emphasis>.
                         </para>
                         <para>
-                            For example, having a resource at<literal>http://server.com/api/management/user</literal>, that
-                            returns response with<literal>Location: foo</literal>, while the root of the app is
+                            For example, having a resource at <literal>http://server.com/api/management/user</literal>, that
+                            returns response with <literal>Location: foo</literal>, while the root of the app is
                             <literal>http://server.com/api</literal>, the resulting URI will be:
                             <simplelist>
                                 <member>with Jersey 2.21 and earlier:
@@ -247,7 +247,7 @@
                         <para>
                             Alternatively, the entire URI resolving logic can be switched off by newly
                             introduced &jersey.server.ServerProperties.LOCATION_HEADER_RELATIVE_URI_RESOLUTION_DISABLED; property.
-                            If the value is<literal>true</literal>, Jersey will not change the URI contained in the
+                            If the value is <literal>true</literal>, Jersey will not change the URI contained in the
                             <literal>Location</literal>
                             header at all (even if this behaviour may not match with behaviour described in JavaDoc).
                         </para>
@@ -266,9 +266,9 @@
                 <itemizedlist>
                     <listitem>
                         <para>
-                            New parameter,<literal>org.glassfish.hk2.api.ServiceLocator</literal>, has been added
+                            New parameter, <literal>org.glassfish.hk2.api.ServiceLocator</literal>, has been added
                             to &jersey.server.spi.ExternalRequestScope; methods. This is to allow 3rd party component providers to
-                            hook up with the actual HK2 locator in case of multiple Jersey applications are running in paralell
+                            hook up with the actual HK2 locator in case of multiple Jersey applications are running in parallel
                             within a single 3rd party component container. The change was driven by CDI/Servlet requirements.
                         </para>
                     </listitem>
@@ -286,7 +286,7 @@
                 <itemizedlist>
                     <listitem>
                         <para>
-                            New method,<literal>close</literal>, has been added to &jersey.server.ResourceFinder;. It's intention
+                            New method, <literal>close</literal>, has been added to &jersey.server.ResourceFinder;. Its intention
                             is to release allocated/opened resources (such as streams) without a need to iterate through the
                             whole &lit.jersey.server.ResourceFinder;.
                         </para>
@@ -490,7 +490,7 @@
             <section>
                 <title>Performance gain when using Sub-Resource Locators</title>
                 <para>
-                    We improved the performance for using sub-resource locators in an Jersey application. The performance gains
+                    We improved the performance for using sub-resource locators in a Jersey application. The performance gains
                     are available for cases when the sub-resource locator method returns either a resource class (return value is
                     e.g.
                     <literal>Class&lt;?&gt;</literal>
@@ -588,7 +588,7 @@
                     example,<link xlink:href='https://github.com/jersey/jersey/tree/master/examples/helloworld-weld'>
                     helloworld-weld</link>, has been introduced to demonstrate the new feature using Grizzly HTTP server. Another
                     example application,<link xlink:href='https://github.com/jersey/jersey/tree/master/examples/cdi-webapp'>
-                    cdi-webapp</link>, has been updated so that it enables Apache Tomcat Server deployment.
+                    cdi-webapp</link>, has been updated so it enables Apache Tomcat Server deployment.
                 </para>
             </section>
 
@@ -666,13 +666,12 @@
                             For performance purposes a new server property &jersey.server.ServerProperties.MONITORING_ENABLED; has
                             been introduced. It is possible to enable just basic almost static monitoring information using the
                             property. It allows to inject &jersey.server.monitoring.ApplicationInfo; object, renamed original
-                            class<literal>org.glassfish.jersey.server.monitoring.ApplicationStatistics</literal>.
+                            class <literal>org.glassfish.jersey.server.monitoring.ApplicationStatistics</literal>.
                             And &jersey.server.monitoring.MonitoringStatistics; no more have a reference to<literal>
                             ApplicationStatistics</literal>, method
                             <literal>getApplicationStatistics()</literal>
                             has been removed.
                         </para>
-                        gitc
                     </listitem>
                 </itemizedlist>
             </para>
@@ -723,7 +722,7 @@
                     We have reintroduced support for JSON processing via Jackson 1.x JSON provider (1.9.11). In order to use
                     Jackson 1 in your application you need to add
                     <literal>jersey-media-json-jackson1</literal>
-                    module (+ it's dependencies) to your class-path and register
+                    module (+ its dependencies) to your class-path and register
                     <literal>Jackson1Feature</literal>
                     in your application (server or client).
                 </para>
@@ -812,7 +811,7 @@
                 <para>
                     Our media module that supports working with JSON via Jackson library has been updated to use Jackson 2.x
                     (2.3.2). All samples and tests have been rewritten to use Jackson 2 as well. In order to use Jackson 2 in your
-                    application you need to add jersey-media-json-jackson (+ it's Jackson dependencies) to your class-path and
+                    application you need to add jersey-media-json-jackson (+ its Jackson dependencies) to your class-path and
                     register
                     <literal>JacksonFeature</literal>
                     in your application.
@@ -842,7 +841,7 @@
                     default). You can now run the tests in parallel using either JUnit or TestNG. See chapters dedicated to TestNG
                     and parallel testing for more information:
                     <xref linkend="testng"/>
-                    and<xref linkend="parallel"/>.
+                    and <xref linkend="parallel"/>.
                 </para>
             </section>
         </section>
@@ -865,7 +864,7 @@
                     </listitem>
                     <listitem>
                         <para>
-                            Automatic registration of<literal>MessageBodyWriter</literal>,
+                            Automatic registration of <literal>MessageBodyWriter</literal>,
                             <literal>MessageBodyReaders</literal>
                             and
                             <literal>ExceptionMappers</literal>
@@ -873,7 +872,7 @@
                             <literal>META-INF/services</literal>
                             mechanism has been removed. Disabling the automatic registration of providers via
                             <literal>META-INF/services</literal>
-                            may affect 3rd party libraries (i.e. Jackson 2.x) that are using this mechanism to register it's
+                            may affect 3rd party libraries (i.e. Jackson 2.x) that are using this mechanism to register its
                             providers. In order to restore this functionality the
                             <literal>org.glassfish.jersey.ext:jersey-metainf-services</literal>
                             has to be added on the classpath. Otherwise such providers has to be registered manually.
@@ -921,7 +920,7 @@
                         <para>
                             &jersey.sse.SseFeature; now gets automatically discovered and enabled if the SSE module is present on
                             the class path. This behavior can be suppressed by setting &jersey.sse.SseFeature.DISABLE_SSE;
-                            property to<literal>true</literal>. The behavior can also be selectively suppressed in either client
+                            property to <literal>true</literal>. The behavior can also be selectively suppressed in either client
                             or server runtime by setting the &jersey.sse.SseFeature.DISABLE_SSE_CLIENT;
                             or &jersey.sse.SseFeature.DISABLE_SSE_SERVER; property respectively.
                         </para>
@@ -1193,7 +1192,7 @@
                         <para>
                             MVC support: method
                             <literal>writeTo</literal>
-                            of &jersey.server.mvc.TemplateProcessor; was modified by adding an argument<literal>MultivaluedMap&lt;String,
+                            of &jersey.server.mvc.TemplateProcessor; was modified by adding an argument <literal>MultivaluedMap&lt;String,
                             Object&gt; httpHeaders</literal>. This is an incompatible change (the method was modified directly in
                             the interface). All Jersey provided MVC implementation were adjusted but if you have your own MVC
                             implementation then you need to modify the method signature of the implementation.
@@ -1201,7 +1200,7 @@
                     </listitem>
                     <listitem>
                         <para>
-                            A minor JAX-RS incompatibility issue has been recently discovered and reported (see<link
+                            A minor JAX-RS incompatibility issue has been recently discovered and reported (see <link
                                 xlink:href="https://java.net/jira/browse/JERSEY-2387">JERSEY-2387</link>). As part of the fix,
                             minor breaking changes related to URI resolving and creation have been introduced in the behavior
                             of &jaxrs.core.UriBuilder;, &jaxrs.core.Link.Builder; and &jaxrs.client.WebTarget; classes. It is no
@@ -1370,8 +1369,8 @@
                         WADL is by default displayed in the simplified form. It does not contain supporting resources like OPTIONS
                         methods or
                         <literal>/application.wadl</literal>
-                        itself. In order to get the full WADL use query param<literal>detail=true</literal>. For example make a
-                        GET request to<literal>http://localhost:8080/application.wadl?detail=true</literal>.
+                        itself. In order to get the full WADL use query param <literal>detail=true</literal>. For example make a
+                        GET request to <literal>http://localhost:8080/application.wadl?detail=true</literal>.
                     </para>
                 </listitem>
             </itemizedlist>
@@ -1390,7 +1389,7 @@
                         methods or
                         <literal>/application.wadl</literal>
                         itself. In order to get the full WADL use query param<literal>detail=true</literal>. For example make a
-                        GET request to<literal>http://localhost:8080/application.wadl?detail=true</literal>.
+                        GET request to <literal>http://localhost:8080/application.wadl?detail=true</literal>.
                     </para>
                 </listitem>
             </itemizedlist>
@@ -1527,7 +1526,7 @@
                             <literal>org.glassfish.jersey.spi.RequestsExecutorsProvider</literal>. It has been also extended with
                             an additional
                             <literal>releaseRequestingExecutor</literal>
-                            method to address executor shutdown handling issues reported in<link
+                            method to address executor shutdown handling issues reported in <link
                                 xlink:href='https://java.net/jira/browse/JERSEY-2205'>JERSEY-2205</link>. As such, any custom
                             implementation of the SPI is now required to implement the new method. (Note that the SPI has been
                             removed in Jersey 2.18 - see the Jersey 2.18 release migration guide section for more details.)
@@ -1548,7 +1547,7 @@
                     <para>
                         The unsupported
                         <literal>ClientProperties.BUFFER_RESPONSE_ENTITY_ON_EXCEPTION</literal>
-                        property, with value of<literal>jersey.config.client.bufferResponseEntityOnException</literal>, has been
+                        property, with value of <literal>jersey.config.client.bufferResponseEntityOnException</literal>, has been
                         removed from the API. Since Jersey 2.4 where
                         <link xlink:href='https://java.net/jira/browse/jersey-2157'>JERSEY-2157</link>
                         issue has been fixed, Jersey client runtime automatically buffers error response entities. This behavior
@@ -1573,7 +1572,7 @@
                         methods have been introduced instead in Jersey 2.3 for consistency with other parts of client-side JAX-RS
                         API. Access to the raw SSE event data content is provided via a &lit.jersey.sse.InboundEvent;'s
                         <literal>byte[] getRawData()</literal>
-                        method that has been too introduced in Jersey 2.3.
+                        method that has been introduced in Jersey 2.3 as well.
                     </para>
                 </listitem>
                 <listitem>
@@ -1610,7 +1609,7 @@
                         Generic &jersey.server.Broadcaster; methods for adding/removing &jersey.server.BroadcasterListener;
                         registrations have been renamed from
                         <literal>addBroadcasterListener/removeBroadcasterListener</literal>
-                        to simply<literal>add/remove</literal>.
+                        to simply <literal>add/remove</literal>.
                     </para>
                 </listitem>
                 <listitem>
@@ -1744,7 +1743,7 @@
 
                     Containers, which support the reload functionality implement the
                     <literal>ContainerListener</literal>
-                    interface, so that once you get access to the actual container instance, you could call it's
+                    interface, so that once you get access to the actual container instance, you could call its
                     <literal>onReload</literal>
                     method and get the container re-load the config. The second interface helps you to obtain the actual container
                     instance reference. An example on how things are wired together follows.
@@ -2115,7 +2114,7 @@
                             Jackson</literal>,<literal>Jettison</literal>) can be used as well. The relevant feature has to be
                             registered (and dependency added) and custom implementation of
                             <literal>ContextResolver</literal>
-                            has to be provided. See the code snippets in the<link linkend="json.jackson">related chapter</link>.
+                            has to be provided. See the code snippets in the <link linkend="json.jackson">related chapter</link>.
                         </para>
                         <para>
                             For more on particular
@@ -2190,7 +2189,7 @@
                 <para>
                     As mentioned, the centralized configuration of Jersey&nbsp;1's
                     <literal>JSONConfiguration</literal>
-                    does not have a direct equivalent in Jersey&nbsp;2. Each provider has it's own way to be configured. Detailed
+                    does not have a direct equivalent in Jersey&nbsp;2. Each provider has its own way to be configured. Detailed
                     description of each method and property is out of scope of this migration guide and can be found in the
                     documentation and APIs of the relevant providers and/or the relevant Jersey module API. Bellow are several
                     basic examples how to configure certain options when using MOXy with Jersey's
@@ -2237,7 +2236,7 @@
                     <literal>Marshaller</literal>
                     and/or
                     <literal>Unmarshaller</literal>
-                    using:<literal>MoxyJsonConfig</literal>'s<literal>property()</literal>,
+                    using: <literal>MoxyJsonConfig</literal>'s <literal>property()</literal>,
                     <literal>marshallerProperty()</literal>
                     and
                     <literal>unmarshallerProperty()</literal>
@@ -2245,7 +2244,7 @@
                 </para>
             </section>
             <para>
-                More on the JSON Support topic can be found in<xref linkend="json"/>.
+                More on the JSON Support topic can be found in <xref linkend="json"/>.
             </para>
         </section>
     </section>
diff --git a/docs/src/main/docbook/monitoring.xml b/docs/src/main/docbook/monitoring.xml
index aab0cd9..db9f1b3 100644
--- a/docs/src/main/docbook/monitoring.xml
+++ b/docs/src/main/docbook/monitoring.xml
@@ -40,7 +40,7 @@
                 </para>
             </important>
             <para>
-                Jersey provides functionality for monitoring JAX-RS/Jersey applications. Application monitoring is useful in cases
+                Jersey provides functionality for monitoring JAX-RS/Jersey applications. Application monitoring is useful
                 when you need to identify the performance hot-spots in your JAX-RS application, observe
                 execution statistics of particular resources or listen to application
                 or request lifecycle events. Note that this functionality is Jersey-specific extension to JAX-RS API.
@@ -54,7 +54,7 @@
                         <listitem>
                             <para>
                                 Event listeners allow users to receive and process a predefined set of events that occur during
-                                a application lifecycle (such as application initialization, application destroy) as well as
+                                an application lifecycle (such as application initialization, application destroy) as well as
                                 request processing lifecycle events (request started, resource method finished, exception thrown,
                                 etc.). This feature is always enabled in Jersey server runtime and is leveraged by the other
                                 monitoring features.
@@ -82,7 +82,7 @@
                                 is able to expose the statistics as JMX MBeans (for example
                                 &jersey.server.monitoring.ApplicationMXBean;).
                                 Jersey monitoring MXBeans can be accessed programmatically using JMX APIs or browsed via JMX-enabled
-                                tool (<literal>JConsole</literal> for example). This functionality is, too,  by default disabled for
+                                tool (<literal>JConsole</literal> for example). This functionality is also disabled by default for
                                 performance reasons and must be enabled if needed.
                             </para>
                         </listitem>
@@ -196,7 +196,7 @@
             </para>
 
             <para>
-                Once the listeners and the monitored resource is defined, it's time to initialize our application. The following
+                Once the listeners and the monitored resource are defined, it's time to initialize our application. The following
                 piece of code shows a &jersey.server.ResourceConfig; that is used to initialize the application (please
                 note that only &lit.jersey.server.monitoring.ApplicationEventListener; is registered as provider).
 
@@ -220,7 +220,7 @@
                 from an <literal>ApplicationEventListener.onRequest</literal> method and not any other requests. In our case the
                 returned request event listener keeps information about the request number of the current request and a start time of
                 the request which is later used to print out the request processing times statistics. This demonstrates the principle
-                of listening to request events: for one request there is a one instance which can be used to hold all the information
+                of listening to request events: for one request there is one instance which can be used to hold all the information
                 about the particular request. In other words, &lit.jersey.server.monitoring.RequestEventListener; is designed to be
                 implicitly request-scoped.
             </para>
@@ -456,7 +456,7 @@
                     of &lit.jersey.server.monitoring.MonitoringStatistics; does not make any assumptions about mutability of
                     monitoring statistics instances (to allow future optimizations and changes in implementation strategy). In
                     order to get always latest statistics, we recommend injecting a &jee6.javax.inject.Provider; rather than a
-                    direct reference and use it's <literal>get()</literal> method to retrieve the latest statistics. For example,
+                    direct reference and use its <literal>get()</literal> method to retrieve the latest statistics. For example,
                     in singleton resources the use of the technique is very important otherwise statistics might correspond
                     to the time when singleton was firstly created and might not update since that time.
                 </para>
@@ -533,21 +533,21 @@
                     <link linkend="resource-builder">"Programmatic API for Building Resources"</link>), one Java resource class
                     can be an endpoint for resource methods on many different URIs. And also one URI can be served by method from
                     many different Java classes. Therefore both views are not to be compared 1:1. Instead they provide
-                    different loggical views on your JAX-RS application. This monitoring feature can also help when designing
+                    different loggical views on your JAX-RS application. This monitoring feature can also be helpful when designing
                     the JAX-RS APIs as it provides nice view on available root application URIs.
                 </para>
                 <para>
                     Both logical views on the resources exposed by application share few common principles. A single resource entry
                     is always a set of resource methods which are available under the <literal>methods</literal> sub-group. Statistics
                     can be found in MBeans <literal>MethodTimes</literal> and <literal>RequestTimes</literal>.
-                    <literal>MethodTimes</literal> contains statistics measured on on resource methods (duration of execution of a
+                    <literal>MethodTimes</literal> contains statistics measured on resource methods (duration of execution of a
                     code of the a resource method), whereas <literal>RequestTimes</literal> contains statistics of an entire request
                     execution (not only a time of the execution of the resource method but the overall time of the execution of whole
                     request by Jersey runtime). Another useful information is that statistics directly under resource (not under
                     the <literal>methods</literal> sub-group) contains summary of statistics for all resource methods grouped in the
                     resource entry.
                 </para>
-                <para>Additional useful details that about statistics</para>
+                <para>Additional useful details about statistics</para>
                 <itemizedlist>
                     <listitem><para><literal>Global->Configuration->Registered(Classes/Instances)</literal>:
                         registered resource classes and instances by the user (i.e., not added by &jersey.server.ModelProcessor;
@@ -612,7 +612,7 @@
                 </para>
                 <para>
                     To reiterate, exposing Jersey MXBeans and the calculating monitoring statistics may have an performance impact
-                    on your application and therefore should be enabled only when needed. Also, please note, that it Jersey
+                    on your application and therefore should be enabled only when needed. Also, please note, that Jersey
                     monitoring is exposing quite a lot of information about the monitored application which might be viewed as
                     problematic in some cases (e.g. in production server deployments).
                 </para>
diff --git a/docs/src/main/docbook/mp-config.xml b/docs/src/main/docbook/mp-config.xml
index 36c1e45..a201cf1 100644
--- a/docs/src/main/docbook/mp-config.xml
+++ b/docs/src/main/docbook/mp-config.xml
@@ -30,8 +30,8 @@
     <title>Jersey configuration</title>
     <para>
         This chapter provides Jersey configuration basics which includes configuration using default configuration
-        provider (included in Jersey by default) using system properties. And micro-profile configuration extension
-        which allows plugging-in of configuration modules based on micro profile configuration specification
+        provider (included in Jersey by default) using system properties, and micro-profile configuration extension
+        which allows plugging-in of configuration modules based on micro profile configuration specification.
     </para>
     <section xml:id="default-config">
         <title>Jersey default configuration provider</title>
diff --git a/docs/src/main/docbook/mvc.xml b/docs/src/main/docbook/mvc.xml
index 171e7af..81c58ac 100644
--- a/docs/src/main/docbook/mvc.xml
+++ b/docs/src/main/docbook/mvc.xml
@@ -284,7 +284,7 @@
         <title>Handling errors with MVC</title>
 
         <para>
-            In addition to &jersey.server.mvc.Template; a &jersey.server.mvc.ErrorTemplate; annotation has been introduced in
+            In addition to &jersey.server.mvc.Template; an &jersey.server.mvc.ErrorTemplate; annotation has been introduced in
             Jersey 2.3. The purpose of this annotation is to bind the model to an error view in case an exception has been raised during
             processing of a request. This is true for any exception thrown after the resource matching phase (i.e. this not only
             applies to JAX-RS resources but providers and even Jersey runtime as well). The model in this case is the thrown exception
@@ -292,7 +292,7 @@
         </para>
         <para>
             <xref linkend="mvc.example.error.simple"/> shows how to use &lit.jersey.server.mvc.ErrorTemplate; on a resource method.
-            If all goes well with the method processing, then the <literal>/short-link</literal> template is used to as page sent
+            If all goes well with the method processing, then the <literal>/short-link</literal> template is used as page sent
             to the user. Otherwise if an exception is raised then the <literal>/error-form</literal> template is shown to the user.
         </para>
         <example xml:id="mvc.example.error.simple">
@@ -321,7 +321,7 @@
             <title>MVC &amp; Bean Validation</title>
 
             <para>
-                &lit.jersey.server.mvc.ErrorTemplate; can be used in also with Bean Validation to display specific error pages in
+                &lit.jersey.server.mvc.ErrorTemplate; can also be used with Bean Validation to display specific error pages in
                 case the validation of input/output values fails for some reason. Everything works as described above except the
                 model is not the thrown exception but rather a list of &jersey.ext.ValidationError;s. This list can be iterated in
                 the template and all the validation errors can be shown to the user in a desirable way.
@@ -465,7 +465,7 @@
                 <step>
                     <para>
                         if <literal>ServletContext.getResource</literal>, <literal>Class.getResource</literal> or
-                        <literal>File.exists</literal>returns a non-&lit.null; value for the reference then
+                        <literal>File.exists</literal> returns a non-&lit.null; value for the reference then
                         return the reference as the processable template reference otherwise return &lit.null;
                         (to indicate the absolute reference has not been resolved by the Mustache template processor).
                     </para>
@@ -541,7 +541,7 @@
                 <step>
                     <para>
                         if <literal>ServletContext.getResource</literal>, <literal>Class.getResource</literal> or
-                        <literal>File.exists</literal>returns a non-&lit.null; value for the reference then
+                        <literal>File.exists</literal> returns a non-&lit.null; value for the reference then
                         return the reference as the processable template reference otherwise return &lit.null;
                         (to indicate the absolute reference has not been resolved by the Freemarker template processor).
                     </para>
diff --git a/docs/src/main/docbook/representations.xml b/docs/src/main/docbook/representations.xml
index 8a10427..fda8d6a 100644
--- a/docs/src/main/docbook/representations.xml
+++ b/docs/src/main/docbook/representations.xml
@@ -81,7 +81,7 @@
             request parameters, the method parameter associated with the
             representation being consumed does not require annotating. In other words the
             representation (entity) parameter does not require a specific 'entity' annotation. A method parameter
-            without a annotation is an entity. A maximum of
+            without an annotation is an entity. A maximum of
             one such unannotated method parameter may exist since there may only be a
             maximum of one such representation sent in a request.
         </para>
@@ -367,7 +367,7 @@
 
         <para>Notice that in this example the constructor of a resource class is used
             to perform actions that may otherwise have to be duplicated to
-            invoked for each resource method. The life cycle of resource classes is per-request
+            be invoked for each resource method. The life cycle of resource classes is per-request
             which means that the resource instance is created for each request and therefore
             can work with request parameters and for example make changes to the request processing by
             throwing an exception as it is shown in this example.
diff --git a/docs/src/main/docbook/rx-client.xml b/docs/src/main/docbook/rx-client.xml
index fe46cab..db91eef 100644
--- a/docs/src/main/docbook/rx-client.xml
+++ b/docs/src/main/docbook/rx-client.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2014, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2014, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -165,7 +165,7 @@
 }</programlisting>
                 </example>
 
-                The downside of this approach is it's slowness. You need to sequentially process all the independent requests which
+                The downside of this approach is its slowness. You need to sequentially process all the independent requests which
                 means that you're wasting resources. You are needlessly blocking threads, that could be otherwise used for some real work.
             </para>
             <para>
@@ -534,7 +534,7 @@
                 &rxjava.link;, contributed by Netflix, is probably the most advanced reactive library for Java at the moment. It's
                 used for composing asynchronous and event-based programs by using observable sequences. It uses the
                 <link xlink:href="&wikipedia.uri;Observer_pattern">observer pattern</link> to support these sequences of data/events
-                via it's &rxjava.Observable; entry point class which implements the Reactive Pattern. &lit.rxjava.Observable; is
+                via its &rxjava.Observable; entry point class which implements the Reactive Pattern. &lit.rxjava.Observable; is
                 actually the parameter type in the RxJava's extension of &jaxrs.client.RxInvoker;, called
                 &jersey.ext.rx.client.rxjava.RxObservableInvoker;. This means that the return type of HTTP method calls is
                 &lit.rxjava.Observable; in this case (accordingly parametrized).
@@ -611,7 +611,7 @@
                 &rxjava.link;, contributed by Netflix, is probably the most advanced reactive library for Java at the moment. It's
                 used for composing asynchronous and event-based programs by using observable sequences. It uses the
                 <link xlink:href="&wikipedia.uri;Observer_pattern">observer pattern</link> to support these sequences of data/events
-                via it's &rxjava2.Flowable; entry point class which implements the Reactive Pattern. &lit.rxjava2.Flowable; is
+                via its &rxjava2.Flowable; entry point class which implements the Reactive Pattern. &lit.rxjava2.Flowable; is
                 actually the parameter type in the RxJava's extension of &jaxrs.client.RxInvoker;, called
                 &jersey.ext.rx.client.rxjava2.RxFlowableInvoker;. This means that the return type of HTTP method calls is
                 &lit.rxjava2.Flowable; in this case (accordingly parametrized).
diff --git a/docs/src/main/docbook/sse.xml b/docs/src/main/docbook/sse.xml
index 8d89922..2e46ee8 100644
--- a/docs/src/main/docbook/sse.xml
+++ b/docs/src/main/docbook/sse.xml
@@ -216,18 +216,18 @@
                 the client can read headers and starts listening for individual events.
             </para>
             <para>
-                In the<xref linkend="example-simple-sse-jaxrs"/>, the resource method creates a new thread that sends a
+                In the <xref linkend="example-simple-sse-jaxrs"/>, the resource method creates a new thread that sends a
                 sequence of 10 events. There is a 1 second delay between two subsequent events as indicated in a comment. Each
                 event is represented by <literal>jakarta.ws.rs.sse.OutboundSseEvent</literal> type and is built with a help of a
                 provided <literal>Builder</literal>. The <literal>Builder</literal> is obtain via the injected instance
                 (actually, it is a singleton) of <literal>jakarta.ws.rs.sse.Sse</literal> (the
                 <literal>newEventBuilder()</literal>
-                method. The <literal>OutboundSseEvent</literal> implementation reflects the standardized format of
+                method). The <literal>OutboundSseEvent</literal> implementation reflects the standardized format of
                 SSE messages and contains properties that represent <literal>name</literal> (for named events),
                 <literal>comment</literal>, <literal>data</literal> or <literal>id</literal>. The code also sets the
                 event data media type using the <literal>mediaType(MediaType)</literal> method on the
                 <literal>eventBuilder</literal>. The media type, together with the data type set by the
-                <literal>data(Class, Object></literal>
+                <literal>data(Class, Object)</literal>
                 method (in our case <literal>String.class</literal>), is used
                 for serialization of the event data. Note that the event data media type will not be written to any headers as
                 the response <literal>Content-type</literal> header is already defined by the &lit.jaxrs.Produces; and set to
@@ -361,7 +361,7 @@
     @GET
     @Produces(MediaType.SERVER_SENT_EVENTS)
     public void listenToBroadcast(@Context SseEventSink eventSink) {
-        this.broadcaster.subscribe(eventSink);
+        this.broadcaster.register(eventSink);
     }
 }
                     </programlisting>
@@ -369,7 +369,7 @@
                 Let's explore the example together. The <literal>BroadcasterResource</literal> resource class is annotated with
                 &jee6.inject.Singleton; annotation which tells Jersey runtime that only a single instance of the resource
                 class should be used to serve all the incoming requests to <literal>/broadcast</literal> path. This is needed as
-                we want to keep an application-wide single reference to the private <literal>broadcaster</literal> field so that
+                we want to keep an application-wide single reference to the private <literal>broadcaster</literal> field so
                 we can use the same instance for all requests. Clients that want to listen to SSE events first send a
                 &lit.http.GET; request to the <literal>BroadcasterResource</literal>, that is handled by the
                 <literal>listenToBroadcast()</literal>
@@ -411,7 +411,7 @@
                 of the registered <literal>EventSink</literal>s as well as it frees all the server-side resources associated with
                 the stale connection.
                 Additionally, the <literal>SseBroadcaster</literal> is implemented to be thread-safe, so that clients can connect
-                and disconnect in any time and <literal>SseBroadcaster</literal> will always broadcast messages to the most recent
+                and disconnect at any time and <literal>SseBroadcaster</literal> will always broadcast messages to the most recent
                 collection of registered and active set of clients.
             </para>
         </section>
@@ -560,7 +560,7 @@
                             method <emphasis>MUST</emphasis> be called, otherwise
                             the subscriber will not receive ANY data. Furthermore, in the current
                             <literal>SseEventSource</literal>
-                            implementation, such a subscriber will block a threadm and will
+                            implementation, such a subscriber will block a thread and will
                             occasionally lead to overflow of an internal buffer in <literal>SseEventSource</literal>. As
                             mentioned, calling <literal>subscription.request(Long.MAX_VALUE)</literal>, e.g. in the registered
                             <literal>onSubscribe</literal>
@@ -596,7 +596,7 @@
                 </para>
             </note>
             <para>
-                By default, when a connection the the SSE endpoint is lost, the event source will use a default delay
+                By default, when a connection to the SSE endpoint is lost, the event source will use a default delay
                 before attempting to reconnect to the SSE endpoint. The SSE endpoint can however control the client-side
                 retry delay by including a special <literal>retry</literal> field value in any event sent to the client.
                 Jersey &jakarta.ws.rs.sse.SseEventSource; implementation automatically tracks any received SSE event
@@ -642,7 +642,7 @@
             <xref linkend="overview-jaxrs"/>
         </para>
         <para>
-            The API contains support SSE support for both - server and client. To use the Jersey-specific SSE API, you need to
+            The API contains SSE support for both - server and client. To use the Jersey-specific SSE API, you need to
             add the dependency to the
         </para>
         <para>
@@ -726,7 +726,7 @@
                     &jersey.server.ChunkedOutput; API for output chunked message processing.
                 </para>
                 <para>
-                    In the<xref linkend="example-simple-sse"/>, the resource method creates a new thread that sends a sequence of
+                    In the <xref linkend="example-simple-sse"/>, the resource method creates a new thread that sends a sequence of
                     10 events. There is a 1 second delay between two subsequent events as indicated in a comment. Each event is
                     represented by &lit.jersey.sse.OutboundEvent; type and is built with a help of an outbound event
                     <literal>Builder</literal>. The &lit.jersey.sse.OutboundEvent; reflects the standardized format of SSE
@@ -1053,7 +1053,7 @@
                         </programlisting>
                     </example>
 
-                    The code above is very similar to the code in<xref linkend="sse.ex.client.eventListener"/>. In this example
+                    The code above is very similar to the code in <xref linkend="sse.ex.client.eventListener"/>. In this example
                     however, the &lit.jersey.sse.EventSource; is constructed directly using a single-parameter constructor.
                     This way, the connection to the SSE endpoint is by default automatically opened at the event source
                     creation. The implementation of the &lit.jersey.sse.EventListener; has been moved into the overridden
diff --git a/docs/src/main/docbook/test-framework.xml b/docs/src/main/docbook/test-framework.xml
index 526d4ee..e32c14e 100644
--- a/docs/src/main/docbook/test-framework.xml
+++ b/docs/src/main/docbook/test-framework.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2012, 2018 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -196,7 +196,7 @@
             <itemizedlist>
                 <listitem>
                     <para>
-                        Extend &jersey.test.JerseyTestNg;, or one of it's inner classes &jersey.test.JerseyTestNg.ContainerPerClassTest;
+                        Extend &jersey.test.JerseyTestNg;, or one of its inner classes &jersey.test.JerseyTestNg.ContainerPerClassTest;
                         / &jersey.test.JerseyTestNg.ContainerPerMethodTest;, instead of &jersey.test.JerseyTest;.
                     </para>
                 </listitem>
@@ -389,7 +389,7 @@
 &lt;/dependency&gt;</programlisting>
 
                 As indicated, the "container" exposed by this module is just a wrapper or stub, that redirects all request to
-                a configured host and port. Writing tests for this container is same as for any other but you have to provide
+                a configured host and port. Writing tests for this container is similar to any other but you have to provide
                 the information about host and port during the test execution:
 
                 <screen>mvn test -Djersey.test.host=myhost.org -Djersey.config.test.container.port=8080</screen>
diff --git a/docs/src/main/docbook/user-guide.xml b/docs/src/main/docbook/user-guide.xml
index 0247500..bddbfac 100644
--- a/docs/src/main/docbook/user-guide.xml
+++ b/docs/src/main/docbook/user-guide.xml
@@ -39,7 +39,7 @@
         </para>
         <para>
             If you would like to contribute to the guide or have questions on things not covered in our docs, please
-            contact us at<link xlink:href="mailto:jersey-dev@eclipse.org">users@jersey.java.net</link>. Similarly,
+            contact us at <link xlink:href="mailto:jersey-dev@eclipse.org">users@jersey.java.net</link>. Similarly,
             in case you spot any errors in the Jersey documentation, please report them by filing a new issue in our
             <link xlink:href="https://github.com/eclipse-ee4j/jersey/issues">Jersey JIRA Issue Tracker</link>
             under
diff --git a/docs/src/main/docbook/wadl.xml b/docs/src/main/docbook/wadl.xml
index 62599a4..991f8e4 100644
--- a/docs/src/main/docbook/wadl.xml
+++ b/docs/src/main/docbook/wadl.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 <!--
 
-    Copyright (c) 2012, 2019 Oracle and/or its affiliates. All rights reserved.
+    Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved.
 
     This program and the accompanying materials are made available under the
     terms of the Eclipse Public License v. 2.0, which is available at
@@ -35,7 +35,7 @@
             Jersey contains support for
             <link xlink:href='https://javaee.github.io/wadl/'>Web Application Description Language (WADL)</link>. WADL is
             a XML description of a deployed RESTful web application. It contains model of the deployed resources, their
-            structure, supported media types, HTTP methods and so on. In a sense, WADL is a similar to the WSDL
+            structure, supported media types, HTTP methods and so on. In a sense, WADL is similar to the WSDL
             (Web Service Description Language) which describes SOAP web services. WADL is however specifically designed
             to describe RESTful Web resources.
         </para>
@@ -242,7 +242,7 @@
             and one &lit.http.GET; method which return this WADL. There is also
             a sub-resource with a path defined by path param <literal>{path}</literal>. This means that you can request
             a resource on the URI <literal>http://localhost:9998/application.wadl/something</literal>.
-            This is used only to return an external grammar if there is any attached. Such a external grammar can be
+            This is used only to return an external grammar if there is any attached. Such an external grammar can be
             for example an <literal>XSD</literal> schema of the response entity which if the response entity is a JAXB bean.
             An external grammar support via Jersey <emphasis>extended WADL support</emphasis> is described in sections below.
         </para>
@@ -256,7 +256,7 @@
             primary use case of getting formatted data.
         </para>
         <para>
-            Let's now send an HTTP &lit.http.OPTIONS; request to <literal>"country/{id}"</literal> resource using the the
+            Let's now send a HTTP &lit.http.OPTIONS; request to <literal>"country/{id}"</literal> resource using the the
             <literal>curl</literal> command:
             <programlisting linenumbering="unnumbered">curl -X OPTIONS -H "Allow: application/vnd.sun.wadl+xml" \
     -v http://localhost:9998/country/15</programlisting>
@@ -491,7 +491,7 @@
             The <literal>resource</literal> with <literal>path="customer/{id}"</literal> is similar to the
             country resource from the previous example. There is a path parameter which identifies the customer
             by <literal>id</literal>. The resource contains 2 user-declared methods and again auto-generated
-            &lit.http.OPTIONS; methods added by Jersey. THe resource declares 2 sub-resource locators which are
+            &lit.http.OPTIONS; methods added by Jersey. The resource declares 2 sub-resource locators which are
             represented in the returned WADL document as nested <literal>resource</literal> elements. Note that the sub-resource
             locator <literal>getCustomerAddress()</literal> returns a type CustomerAddressSubResource in the
             method declaration and also in the WADL there is a <literal>resource</literal> element for such