| commit | 84d67de6ddc02372383405bd98c1394afee6ed1b | [log] [tgz] |
|---|---|---|
| author | Bertrand Delacretaz <bdelacretaz@apache.org> | Mon Jun 15 17:09:23 2020 +0200 |
| committer | Bertrand Delacretaz <bdelacretaz@apache.org> | Mon Jun 15 17:09:23 2020 +0200 |
| tree | ccd6c272395e3e3fb50a8d5d3986e518a4c38630 | |
| parent | 126e48fbac86916081aa4d92225e92654c4ca5e3 [diff] |
[maven-release-plugin] prepare release org.apache.sling.servlet-helpers-1.4.2
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 internal request helpers use 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 the SlingInternalRequest helper - see the test code for more.
OutputStream os = new SlingInternalRequest(resourceResolver, slingRequestProcessor, path)
.withResourceType("website/article/news")
.withResourceSuperType("website/article")
.withSelectors("print", "a4")
.withExtension("pdf")
.execute()
.checkStatus(200)
.checkResponseContentType("application/pdf")
.getResponse()
.getOutputStream()
To help map log messages to internal requests, as several of those might be used to handle a single HTTP request, the InternalRequest class sets a log4j Mapped Diagnostic Context (MDC) value with the sling.InternalRequestkey.
The value of that key provides the essential attributes of the current request, so that using a log formatting pattern that displays it, like:
%-5level [%-50logger{50}] %message ## %mdc{sling.InternalRequest} %n
Causes the internal request information to be logged, like in this example (lines folded for readability):
DEBUG [o.a.s.s.internalrequests.SlingInternalRequest ] Executing request using the SlingRequestProcessor ## GET P=/content/tags/monitor+array S=null EXT=json RT=samples/tag(null) WARN [org.apache.sling.engine.impl.request.RequestData ] SlingRequestProgressTracker not found in request attributes ## GET P=/content/tags/monitor+array S=null EXT=json RT=samples/tag(null) DEBUG [o.a.s.s.resolver.internal.SlingServletResolver ] Using cached servlet /apps/samples/tag/json.gql ## GET P=/content/tags/monitor+array S=null EXT=json RT=samples/tag(null)
In these log messages, GET P=/content/tags/monitor+array S=null EXT=json RT=samples/tag(null) points to the current internal request, showing its method, path, selectors, extension, resource type and resource supertype.