commit | 304adcf716bf733fe4af5de97a163d14a8d0aef2 | [log] [tgz] |
---|---|---|
author | Andreas Schaefer <schaefa@iMac.local> | Thu Jun 11 11:25:05 2020 -0700 |
committer | Andreas Schaefer <schaefa@iMac.local> | Thu Jun 11 11:25:05 2020 -0700 |
tree | 68aff043e162822e2c62ba9830df1f6c112bf3a5 | |
parent | f4153b13ae0bbe2fa6f1f5910e4b00ab7ae0e630 [diff] |
Add two tests dealing with checking the response status code after checking the status code
This module is part of the Apache Sling project.
It provides helper mock implementations of the SlingHttpServletRequest
, SlingHttpServletRepsonse
and related classes, along with helpers for internal Sling requests described below.
These helpers can be used for testing, like the Sling Mocks do.
They are also useful for executing internal requests, like in the GraphQL Core module which uses that technique to retrieve GraphQL schemas using the powerful Sling request processing mechanisms.
The InternalRequest
class uses either a SlingRequestProcessor
to execute internal requests using the full Sling request processing pipeline, or a ServletResolver
to resolve and call a Servlet or Script directly.
The direct mode is more efficient but less faithful to the way HTTP requests are processed, as it bypasses all Servlet Filters, in particular.
In both cases, the standard Sling Servlet/Script resolution mechanism is used, which can be useful to execute scripts that are resolved based on the current resource type, for non-HTTP operations. Inventing HTTP method names for this is fine and allows for reusing this powerful resolution mechanism in other contexts.
Here's an example using this InternalRequest
helper - see the test code for more.
OutputStream os = InternalRequest .servletRequest(resourceResolver, servletResolver, "/some/path") .withResourceType("website/article/news") .withResourceSuperType("website/article") .withSelectors("print", "a4") .withExtension("pdf") .execute() .checkStatus(200) .checkResponseContentType("application/pdf") .getResponse() .getOutputStream()