Spring Boot jars are shipped with meta-data files that provide details of all supported
configuration properties. The files are designed to allow IDE developers to offer
contextual help and “code completion” as users are working with application.properties
or application.yml
files.
The majority of the meta-data file is generated automatically at compile time by
processing all items annotated with @ConfigurationProperties
. However, it is possible
to write part of the meta-data manually
for corner cases or more advanced use cases.
Configuration meta-data files are located inside jars under
META-INF/spring-configuration-metadata.json
They use a simple JSON format with items
categorized under either “groups” or “properties” and additional values hint
categorized under "hints":
{"groups": [ { "name": "server", "type": "org.springframework.boot.autoconfigure.web.ServerProperties", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties" }, { "name": "server.tomcat", "type": "org.springframework.boot.autoconfigure.web.ServerProperties$Tomcat", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties", "sourceMethod": "getTomcat()" } ... ],"properties": [ { "name": "server.port", "type": "java.lang.Integer", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties" }, { "name": "server.servlet-path", "type": "java.lang.String", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties", "defaultValue": "/" }, { "name": "server.tomcat.compression", "type": "java.lang.String", "description": "Controls response compression.", "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties$Tomcat", "defaultValue": "off" } ... ],"hints": [ { "name": "server.tomcat.compression", "values": [ { "value": "off", "description": "Disable compression." }, { "value": "on", "description": "Enable compression of responses over 2048 byte." }, { "value": "force", "description": "Enable compression of all responses." }, ], "providers": [ { "name": "any" } ] } ]}
Each “property” is a configuration item that the user specifies with a given value.
For example server.port
and server.servlet-path
might be specified in
application.properties
as follows:
server.port=9090 server.servlet-path=/home
The “groups” are higher level items that don’t themselves specify a value, but instead
provide a contextual grouping for properties. For example the server.port
and
server.servlet-path
properties are part of the server
group.
Note | |
---|---|
It is not required that every “property” has a “group”, some properties might just exist in their own right. |
Finally, “hints” are additional information used to assist the user in configuring a
given property. When configuring the server.tomcat.compression
property, a tool can
use it to offer some auto-completion help for the off
, on
and force
values.
The JSON object contained in the groups
array can contain the following attributes:
Name | Type | Purpose |
---|---|---|
| String | The full name of the group. This attribute is mandatory. |
| String | The class name of the data type of the group. For example, if the group was based
on a class annotated with |
| String | A short description of the group that can be displayed to users. May be omitted if no
description is available. It is recommended that descriptions are a short paragraphs,
with the first line providing a concise summary. The last line in the description should
end with a period ( |
| String | The class name of the source that contributed this group. For example, if the group
was based on a |
| String | The full name of the method (include parenthesis and argument types) that contributed
this group. For example, the name of a |
The JSON object contained in the properties
array can contain the following attributes:
Name | Type | Purpose |
---|---|---|
| String | The full name of the property. Names are in lowercase dashed form (e.g.
|
| String | The class name of the data type of the property. For example, |
| String | A short description of the group that can be displayed to users. May be omitted if no
description is available. It is recommended that descriptions are a short paragraphs,
with the first line providing a concise summary. The last line in the description should
end with a period ( |
| String | The class name of the source that contributed this property. For example, if the
property was from a class annotated with |
| Object | The default value which will be used if the property is not specified. Can also be an array of value(s) if the type of the property is an array. May be omitted if the default value is not known. |
| boolean | Specify if the property is deprecated. May be omitted if the field is not deprecated or if that information is not known. |
The JSON object contained in the hints
array can contain the following attributes:
Name | Type | Purpose |
---|---|---|
| String | The full name of the property that this hint refers to. Names are in lowercase dashed
form (e.g. |
| ValueHint[] | A list of valid values as defined by the |
| ProviderHint[] | A list of providers as defined by the |
The JSON object contained in the values
array of each hint
element can contain the
following attributes:
Name | Type | Purpose |
---|---|---|
| Object | A valid value for the element to which the hint refers to. Can also be an array of value(s) if the type of the property is an array. This attribute is mandatory. |
| String | A short description of the value that can be displayed to users. May be omitted if no
description is available. It is recommended that descriptions are a short paragraphs,
with the first line providing a concise summary. The last line in the description should
end with a period ( |
The JSON object contained in the providers
array of each hint
element can contain the
following attributes:
Name | Type | Purpose |
---|---|---|
| String | The name of the provider to use to offer additional content assistance for the element to which the hint refers to. |
| JSON object | Any additional parameter that the provider supports (check the documentation of the provider for more details). |
It is perfectly acceptable for “property” and “group” objects with the same name to
appear multiple times within a meta-data file. For example, Spring Boot binds
spring.datasource
properties to Hikari, Tomcat and DBCP classes, with each potentially
offering overlap of property names. Consumers of meta-data should take care to ensure
that they support such scenarios.
To improve the user experience and further assist the user in configuring a given property, you can provide additional meta-data that:
The name
attribute of each hint refers to the name
of a property. In the initial
example above, we provide 3 values for the server.tomcat.compression
property: on
,
off
and force
.
If your property is of type Map
, you can provide hints for both the keys and the
values (but not for the map itself). The special .keys
and .values
suffixes must
be used to refer to the keys and the values respectively.
Let’s assume a foo.contexts
that maps magic String values to an integer:
@ConfigurationProperties("foo") public class FooProperties { private Map<String,Integer> contexts; // getters and setters }
The magic values are foo and bar for instance. In order to offer additional content assistance for the keys, you could add the following to the manual meta-data of the module:
{"hints": [ { "name": "foo.contexts.keys", "values": [ { "value": "foo" }, { "value": "bar" } ] } ]}
Note | |
---|---|
Of course, you should have an |
Providers are a powerful way of attaching semantics to a property. We define in the section below the official providers that you can use for your own hints. Bare in mind however that your favorite IDE may implement some of these or none of them. It could eventually provide its own as well.
Note | |
---|---|
As this is a new feature, IDE vendors will have to catch up with this new feature. |
The table below summarizes the list of supported providers:
Name | Description |
---|---|
| Permit any additional values to be provided. |
| Auto-complete the classes available in the project. Usually constrained by a base
class that is specified via the |
| Auto-complete the values of an enum given by the mandatory |
| Auto-complete valid logger names. Typically, package and class names available in the current project can be auto-completed. |
| Auto-complete the available bean names in the current project. Usually constrained
by a base class that is specified via the |
| Auto-complete the available profile names in the project. |
Tip | |
---|---|
No more than one provider can be active for a given property but you can specify several providers if they can all manage the property in some ways. Make sure to place the most powerful provider first as the IDE must use the first one in the JSON section it can handle. If no provider for a given property is supported, no special content assistance is provided either. |
The any provider permits any additional values to be provided. Regular value validation based on the property type should be applied if this is supported.
This provider will be typically used if you have a list of values and any extra values are still to be considered as valid.
The example below offers on
and off
as auto-completion values for system.state
; any
other value is also allowed:
{"hints": [ { "name": "system.state", "values": [ { "value": "on" }, { "value": "off" } ], "providers": [ { "name": "any" } ] } ]}
The class-reference provider auto-completes classes available in the project. This provider supports these parameters:
Parameter | Type | Default value | Description |
---|---|---|---|
|
| none | The fully qualified name of the class that should be assignable to the chosen value. Typically used to filter out non candidate classes. Note that this information can be provided by the type itself by exposing a class with the appropriate upper bound. |
|
| true | Specify if only concrete classes are to be considered as valid candidates. |
The meta-data snippet below corresponds to the standard server.jsp-servlet.class-name
property that defines the JspServlet
class name to use:
{"hints": [ { "name": "server.jsp-servlet.class-name", "providers": [ { "name": "class-reference", "parameters": { "target": "javax.servlet.http.HttpServlet" } } ] } ]}
The enum provider auto-completes the values of the Enum
class referenced via the
target
parameter. This may be handy when the property has a java.lang.String
type
because you don’t want your configuration classes to rely on classes that may not be
on the classpath. This provider supports these parameters:
Parameter | Type | Default value | Description |
---|---|---|---|
|
| none | The fully qualified name of the |
Tip | |
---|---|
By all means, try to define the property with the |
The meta-data snippet below corresponds to the standard spring.jooq.sql-dialect
property that defines the SQLDialect
class name to use:
{"hints": [ { "name": "spring.jooq.sql-dialect", "providers": [ { "name": "enum", "parameters": { "target": "org.jooq.SQLDialect" } } ] }, ]}
The logger-name provider auto-completes valid logger names. Typically, package and class names available in the current project can be auto-completed. Specific frameworks may have extra magic logger names that could be supported as well.
Since a logger name can be any arbitrary name, really, this provider should allow any value but could highlight valid packages and class names that are not available in the project’s classpath.
The meta-data snippet below corresponds to the standard logger.level
property, keys
are logger names and values correspond to the the standard log levels or any custom
level:
{"hints": [ { "name": "logger.level.keys", "values": [ { "value": "root", "description": "Root logger used to assign the default logging level." } ], "providers": [ { "name": "logger-name" } ] }, { "name": "logger.level.values", "values": [ { "value": "trace" }, { "value": "debug" }, { "value": "info" }, { "value": "warn" }, { "value": "error" }, { "value": "fatal" }, { "value": "off" } ], "providers": [ { "name": "any" } ] } ]}
The spring-bean-reference provider auto-completes the beans that are defined in the configuration of the current project. This provider supports these parameters:
Parameter | Type | Default value | Description |
---|---|---|---|
|
| none | The fully qualified name of the bean class that should be assignable to the candidate. Typically used to filter out non candidate beans. |
The meta-data snippet below corresponds to the standard spring.jmx.server
property
that defines the name of the MBeanServer
bean to use:
{"hints": [ { "name": "spring.jmx.server", "providers": [ { "name": "spring-bean-reference", "parameters": { "target": "javax.management.MBeanServer" } } ] } ]}
Note | |
---|---|
The binder is not aware of the meta-data so if you provide that hint, you
will still need to transform the bean name into an actual Bean reference using
the |
The spring-profile-name provider auto-completes the Spring profiles that are defined in the configuration of the current project.
The meta-data snippet below corresponds to the standard spring.profiles.active
property that defines the name of the Spring profile(s) to enable:
{"hints": [ { "name": "spring.profiles.active", "providers": [ { "name": "spring-profile-name" } ] } ]}
You can easily generate your own configuration meta-data file from items annotated with
@ConfigurationProperties
by using the spring-boot-configuration-processor
jar.
The jar includes a Java annotation processor which is invoked as your project is
compiled. To use the processor, simply include spring-boot-configuration-processor
as
an optional dependency, for example with Maven you would add:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-configuration-processor</artifactId> <optional>true</optional> </dependency>
With Gradle, you can use the propdeps-plugin and specify:
dependencies {
optional "org.springframework.boot:spring-boot-configuration-processor"
}
compileJava.dependsOn(processResources)
}
Note | |
---|---|
You need to add |
The processor will pickup both classes and methods that are annotated with
@ConfigurationProperties
. The Javadoc for field values within configuration classes
will be used to populate the description
attribute.
Note | |
---|---|
You should only use simple text with |
Properties are discovered via the presence of standard getters and setters with special
handling for collection types (that will be detected even if only a getter is present). The
annotation processor also supports the use of the @Data
, @Getter
and @Setter
lombok
annotations.
The annotation processor will automatically consider inner classes as nested properties. For example, the following class:
@ConfigurationProperties(prefix="server") public class ServerProperties { private String name; private Host host; // ... getter and setters private static class Host { private String ip; private int port; // ... getter and setters } }
Will produce meta-data information for server.name
, server.host.ip
and
server.host.port
properties. You can use the @NestedConfigurationProperty
annotation on a field to indicate that a regular (non-inner) class should be treated as
if it were nested.
Spring Boot’s configuration file handling is quite flexible; and it often the case that
properties may exist that are not bound to a @ConfigurationProperties
bean. To support
such cases and allow you to provide custom "hints", the annotation processor will
automatically merge items from META-INF/additional-spring-configuration-metadata.json
into the main meta-data file.
The format of the additional-spring-configuration-metadata.json
file is exactly the same
as the regular spring-configuration-metadata.json
. The additional properties file is
optional, if you don’t have any additional properties, simply don’t add it.