Minor modification on documentation chapter (#4408) * Minor modification on documentation Signed-off-by: tvallin <thibault.vallin@oracle.com>
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<?></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<String, + of &jersey.server.mvc.TemplateProcessor; was modified by adding an argument <literal>MultivaluedMap<String, Object> 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 1's <literal>JSONConfiguration</literal> - does not have a direct equivalent in Jersey 2. Each provider has it's own way to be configured. Detailed + does not have a direct equivalent in Jersey 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 & 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 @@ </dependency></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