public final class AnalysisContext extends Object
The analysis context can also contain arbitrary data that can be then accessed by the extensions. This can be used to pass runtime data to the extensions that cannot be captured by their configurations.
The configuration accepted by the builder is actually of 2 forms.
In the old format, the configuration of an extension was nested inside objects corresponding to its exploded extension id. E.g. if the extension had an id of "my.extension", the configuration would look like:
{
"my": {
"extension": {
... the actual configuration of the extension ...
}
}
}
The original idea for doing things this way was that such configuration is easily mergeable
(e.g. when configuration is split across multiple files). There can be only one configuration for each extension and
each extension resides in a different "section" of the configuration. The nesting provides for a seemingly logical
structure of the configuration.
On the other hand the new configuration format is different. It stresses the possibility of having more than 1 configuration for an extension and is more easily translatable into XML. On the other hand it is not that well nested as the old configuration style so it might not look that well logically structured. The new configuration looks like this:
[
{
"extension": "my.extension",
"id": "optional-id",
"configuration": {
... the actual configuration of the extension ...
}
},
{
"extension": "other.extension",
"configuration": {
... the actual configuration of the extension ...
}
}
]
Notice that configurations for different extensions (as well as different configurations for the same extension) are
contained in a top level list. The configurations of different extensions are therefore no longer nested inside each
other, but are "laid out" sequentially.
Each such configuration can optionally be identified by an arbitrary ID which can be used during merging of configuration from multiple sources.
Merging Configurations
As was the case with the old style configurations, the new style configurations can also be merged into each other enabling composition of the final analysis configuration from multiple sources. Because each extension can be configured multiple times in the new style configuration, the identification of the configs to merge is slightly more complicated than it used to.
As long as the "master" configuration and "mergee" configuration contain ids for each configuration of each extension things are simple. Configurations for the same extension with the same ID are merged together, otherwise their added to the list of all extension configurations.
Things get a little bit more complex when the configurations don't have an explicit ID. This use case is supported for seamless conversion from old style configuration (where it didn't make sense to have any kind of configuration ID) to new style configurations that we support now (after all there are quite some clients already having their configurations set up and it would be bad to force them to rewrite them all).
Simply put, id-less configurations are mergeable as long as the master configuration contains only a single configuration for given extension and there is just 1 id-less configuration for given extension in the "mergee".
Modifier and Type | Class and Description |
---|---|
static class |
AnalysisContext.Builder |
Modifier and Type | Method and Description |
---|---|
static AnalysisContext.Builder |
builder()
This method can be used to instantiate a new analysis context builder without the need for prior instantiation
of Revapi.
|
static AnalysisContext.Builder |
builder(PipelineConfiguration pipelineConfiguration)
Returns a new analysis context builder that extracts the information about the available extensions from
the provided pipeline configuration.
|
static AnalysisContext.Builder |
builder(Revapi revapi)
Returns a new analysis context builder that extracts the information about the available extensions from
the provided Revapi instance.
|
AnalysisContext |
copyWithConfiguration(org.jboss.dmr.ModelNode configuration)
This is generally only useful for extensions that delegate some of their functionality to other "internal"
extensions of their own that they need to configure.
|
org.jboss.dmr.ModelNode |
getConfiguration() |
Criticality |
getCriticalityByName(String name) |
Object |
getData(String key) |
Criticality |
getDefaultCriticality(DifferenceSeverity severity) |
Locale |
getLocale() |
API |
getNewApi() |
API |
getOldApi() |
public static AnalysisContext.Builder builder(Revapi revapi)
The extensions have to be known so that both old and new style of configuration can be usefully worked with.
revapi
- the revapi instance to read the available extensions frompublic static AnalysisContext.Builder builder(PipelineConfiguration pipelineConfiguration)
The extensions have to be known so that both old and new style of configuration can be usefully worked with.
pipelineConfiguration
- the pipeline configuration to initialize frompublic static AnalysisContext.Builder builder()
This analysis context will also always uses the default criticalities and severity-to-criticality mapping.
public AnalysisContext copyWithConfiguration(org.jboss.dmr.ModelNode configuration)
configuration
- the configuration to be supplied with the returned analysis context.@Nonnull public org.jboss.dmr.ModelNode getConfiguration()
@Nullable public Criticality getCriticalityByName(String name)
public Criticality getDefaultCriticality(DifferenceSeverity severity)
Copyright © 2014-2020 Lukas Krejci. All Rights Reserved.