log mapping lookup
It is possible to let a processor log all the mapping lookups. It may be useful to understand why a mapping does not work.
If a mapping doesn’t work the first step is to check if the processor is applying it or if it ignores it. The mapping logging will report which mappings were selected for an OpenAPI type.
If the processor doesn’t select the mapping there may be something wrong with the mapping. Maybe a typo.
In case the processor uses the mapping, but it still doesn’t behave as expected it may be a bug.
To control the logging there are two new logging options.
openapi-processor-mapping: v10
options:
package-name: io.openapiprocessor.generated
map:
# ...
logging:
mapping: true (1)
mapping-target: stdout (2)
1 | apart from enabling logging of the mapping lookups in the mapping.yaml you may want to set the mapping-target . |
2 | If set to logger the mapping lookup gets logged at info level to slf4j. If set to stdout the mapping lookup gets written directly to stdout without slf4j. |
Enabling the logging will produce many blocks similar to:
looking for any type mapping of name: 'foo2' path: GET '/fooA' type: 'array' A + global - parameters (type) - name: foo2 => java.util.List<java.lang.String> - name: bar => io.openapiprocessor.Bar1 - name: param @ io.openapiprocessor.ParamAnnotation - type: Bar @ io.openapiprocessor.ParamAnnotation + parameters (name) + name: foo2 => java.util.List<java.lang.String> - name: bar => io.openapiprocessor.Bar1 - name: param @ io.openapiprocessor.ParamAnnotation - type: Bar @ io.openapiprocessor.ParamAnnotation
It always starts with a looking for ..
followed by what it is looking for and the OpenAPI name or type to find, related to which path and its type. Then it lists all mappings checked with their location in the mapping file.
In this case it looks for any mapping of foo2
. any means that it is looking for any mapping, by testing all mappings by priority. More specific mappings have a higher priority and win.
It did not find a mapping by its type (array
in this case), but it found a name mapping for foo2
, indicated by the +
sign. The mappings that do not match get marked with a -
sign.
Here is a snippet from the OpenAPI yaml that is processed here. We have an endpoint fooA
with a query parameter foo2
of type array
.
/fooA:
get:
summary: foo A summary.
description: foo A endpoint
tags: [foo]
parameters:
- in: query
name: foo1
# ...
- in: query
name: foo2
description: parameter foo2
schema:
type: array
items:
type: string
- in: query
name: bar
# ...
responses:
'200':
# ...
The example is a small part of the map many
integration test.
maven
Maven can handle both mapping targets. If the mapping-target
is set to logger
it is necessary to enable the mapping logger io.openapiprocessor.core.converter.mapping
to see any output.
For example by running maven
with:
./mvnw compile -Dorg.slf4j.simpleLogger.log.io.openapiprocessor.core.converter.mapping=info
If the mapping-target
is stdout
the processor output will be written without the usual log level prefix.
summary
to enable logging with maven use:
openapi-processor-mapping: v10
options:
package-name: ...
map:
# ...
logging:
mapping: true
mapping-target: stdout
to get the simple output, or
openapi-processor-mapping: v10
options:
package-name: ...
map:
# ...
logging:
mapping: true
to get the log level based output. Remember to enable the logger in this case as described above.