Adding the restrictions we have in place for the wildcard support so that we can consider the same ones for the config tree.

1. The location cannot contain multiple wildcards.
2. The wildcard must be at the end of the path.
3. Locations with wildcard directories are restricted to one-level deep.
4. Locations with wildcard directories are sorted alphabetically.

Spring Security is adding an enhancement that allows configuring HTTP security by exposing a SecurityFilterChain bean. In this case, there is no need to extend WebSecurityConfigurerAdapter. See https://github.com/spring-projects/spring-security/issues/8804.

Currently Spring Boot applies a default security configuration when no WebSecurityConfigurerAdapter bean is present. Going forward, it should also check if a SecurityFilterChain bean is present before applying a default security configuration.

Spring Security still needs to make some changes for making WebSecurity work with bean style SecurityFilterChain. We use WebSecurity to configure ignored paths for the Cloud Foundry actuators. Until that's sorted we can't move to the bean style config for our own auto-configurations. We should open a separate issue for https://github.com/spring-projects/spring-boot/issues/22739#issuecomment-669545630 once that's done.

We are not going to change this behavior because this is consistent with how maps from various property sources get merged.

Forward port of issue #22895 to 2.4.x.

Forward port of issue #21542 to 2.3.x.

E.g. there is a configuration application.yaml

application:
  a: some string
  b:
    - 1
    - 2

I try to override these properties with

SPRING_APPLICATION_JSON={"application": {"a": null, "b": null}}

And it doesn't override values from yaml file, but when values in json are not null everything works fine.

Forward port of issue #22895 to 2.4.x.

Forward port of issue #21542 to 2.3.x.

We have decided to add the values specified by the user as is to the property source for SPRING_APPLICATION_JSON. For Collections, this means that [] will work as expected. For Maps, an empty map will be added to the property source. However, with the way the MapBinder currently works, an empty map will not be able to override a non-empty map. I've created a separate issue for that. Furthermore, any null values will be skipped by the MapPropertySource so we should document that.

We had some issues recently with the app not being updated. We didn't realize because the old pods were still alive and the service was up.

I thought it made sense to include layertools by default if layers.idx was present by default as well. I'm not sure what you mean by

but in this case should this be included with the launcher?

but we can discuss this on the next call.

Forward port of issue #22774 to 2.4.x.

Forward port of issue #22490 to 2.3.x.

Docs here in this test and on the website say the components.*.details object "May contain nested components that make up the health," but this should no longer be the case with the addition of components.*.components:

https://github.com/spring-projects/spring-boot/blob/a94ab673a3230e89403c1046837359c300f8717c/spring-boot-project/spring-boot-actuator-autoconfigure/src/test/java/org/springframework/boot/actuate/autoconfigure/endpoint/web/documentation/HealthEndpointDocumentationTests.java#L84

https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/actuator-api/html/#health-retrieving-response-structure

The work done in the original issue here seems to have missed updating the documentation: https://github.com/spring-projects/spring-boot/issues/17929

Forward port of issue #22774 to 2.4.x.

Forward port of issue #22490 to 2.3.x.

Reopening since this was in the 2.2.x milestone so we should see if we still want to fix it there.

<!-- Thanks for raising a Spring Boot issue. Please take the time to review the following categories as some of them do not apply here.

🙅 "Please DO NOT Raise an Issue" Cases

• Question STOP!! Please ask questions about how to use something, or to understand why something isn't working as you expect it to, on Stack Overflow using the spring-boot tag.
• Security Vulnerability STOP!! Please don't raise security vulnerabilities here. Head over to https://pivotal.io/security to learn how to disclose them responsibly.
• Managed Dependency Upgrade You DO NOT need to raise an issue for a managed dependency version upgrade as there's a semi-automatic process for checking managed dependencies for new versions before a release. BUT pull requests for upgrades that are more involved than just a version property change are still most welcome.
• With an Immediate Pull Request An issue will be closed as a duplicate of the immediate pull request, so you don't have to raise an issue if you plan to create a pull request immediately.

🐞 Bug report (please don't include this emoji/text, just add your details) Please provide details of the problem, including the version of Spring Boot that you are using. If possible, please provide a test case or sample application that reproduces the problem. This makes it much easier for us to diagnose the problem and to verify that we have fixed it.

🎁 Enhancement (please don't include this emoji/text, just add your details) Please start by describing the problem that you are trying to solve. There may already be a solution, or there may be a way to solve it that you hadn't considered.

TIP: You can always edit your issue if it isn't formatted correctly. See https://guides.github.com/features/mastering-markdown --> Spring Boot version: 2.1.7.RELEASE Java version: 11 App server: WildFly Full 17.0.1.Final

I set spring.profiles.active via web.xml

    <context-param>
        <param-name>spring.profiles.active</param-name>
        <param-value>production</param-value>
    </context-param>

Then I want to override it and tried three ways (after read 24. Externalized Configuration

1. ENV SPRING_PROFILES_ACTIVE=dev (I use Wildfly in Docker) Startup log: (ServerService Thread Pool -- 78) The following profiles are active: dev,production -- Doesn't work
2. Then I tried via Java opts -Dspring.profiles.active=dev Startup log: (ServerService Thread Pool -- 84) The following profiles are active: dev,production-- Doesn't work
3. Then I tried via JSON ENV SPRING_APPLICATION_JSON='{"spring.profiles.active":"dev"}' Startup log: (ServerService Thread Pool -- 82) The following profiles are active: dev -- It works!

If I right understand doc 24. Externalized Configuration, it works incorrect. Spring appended active profile instead of replace. In the first and second cases the profile should remain unchanged (stay production), but it was appended (as result dev, production). Third case was right.

Am I right?

This seems to have been fixed in 2.4.0 snapshots. With an environment variable of SPRING_PROFILES_ACTIVE=dev and the following configuration in web.xml,

<context-param>
        <param-name>spring.profiles.active</param-name>
        <param-value>production</param-value>
</context-param>

the output was The following profiles are active: production.

It's really hard to tell why the promote job failed.

I think we have better logging now so I'm going to close this.

bootstrap.yml is a Spring Cloud feature. Their issue tracker is here.

Currently, Spring Boot filters those resources in src/main/resources:

• application*.yml
• application*.yaml
• application*.properties

It would be useful to add these resources in order to inject pom properties:

• bootstrap.yml
• bootstrap.yaml
• bootstrap.properties

@eleftherias Would you suggest updating our smoke tests and auto-configuration to use the SecurityFilterChain bean instead of extending WebSecurityConfigurerAdapter too?

spring.profiles.include and spring.profiles are not used by the new config data code. However, they are still valid if legacy processing is switched on. We should consider if we want to deprecate them in the metadata.

We also need to update the documentation which mentions spring.profiles.include here.

When running a Spring Boot application on a server that has any environment variable with a prefix of "SERVER_", the ServerProperties class will attempt to use it as a property and subsequently break due to the ignoreUnknownFields = false annotation...

Is it possible to configure the ServerProperties class to have ignoreUnkownFields = true instead (as this seems like the situation that it was designed for)?

Otherwise is there another way around the issue, bearing in mind that I'm currently using the environment variable SPRING_PROFILES_ACTIVE to control which type of environment the app should be running as (dev, stage, prod, etc).

Caused by: org.springframework.beans.NotWritablePropertyException: Invalid property 'PORT_BREAK' of bean class [org.springframework.boot.autoconfigure.web.ServerProperties]: Bean property 'PORT_BREAK' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter?

This looks like a duplicate of #3450. Feel free to reopen if that is not the case.

In reference to #2404 which has been closed...

Spring Booot, being an opinionated framework, should try as hard as possible to adhere to established standards in the industry.

Any application can have three levels of property values: Global default values, Environment default values and Instance specific values.

Profiles, by definition, are Environment default values. They should always be overridden by any instance specific property.

As I see it, you might want to ship default values both for the global settings and for environment specific settings (ie PROD, TEST etc) embeded in the application.

But any instance specific setting should always override the two latter. And, usually, instance specific settings are deployed together with the application on the server.

So to force people to use application-PROD.properties when deploying a production instance and application-TEST on a test instance, is not only wrong, but also a cause of many headaches. I have just spent an hour trying to explain to an infrastructure guy why he must add some text to the properties file based on which profile is used. He did not get it!

So instead of

1. Command line arguments.
2. JNDI attributes from java:comp/env.
3. Java System properties (System.getProperties()).
4. OS environment variables.
5. A RandomValuePropertySource that only has properties in random.*.
6. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
7. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
8. Application properties outside of your packaged jar (application.properties and YAML variants).
9. Application properties packaged inside your jar (application.properties and YAML variants).
10. @PropertySource annotations on your @Configuration classes.
11. Default properties (specified using SpringApplication.setDefaultProperties).

we should have

1. Command line arguments.
2. JNDI attributes from java:comp/env.
3. Java System properties (System.getProperties()).
4. OS environment variables.
5. A RandomValuePropertySource that only has properties in random.*.
6. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
7. Application properties outside of your packaged jar (application.properties and YAML variants).
8. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
9. Application properties packaged inside your jar (application.properties and YAML variants).
10. @PropertySource annotations on your @Configuration classes.
11. Default properties (specified using SpringApplication.setDefaultProperties).

The recent work in 2.4.x related to config file processing and profiles processes file such that application properties outside of the jar take precedence over profile-specific variants inside the jar.

I think this issue has been superseded by the recent profiles related work in 2.4.x.

With version Spring Boot version 2.3.0.RELEASE, tests annotated with @ActiveProfiles("test") fail to resolve variable spring.profiles.active.

The issue is not present on version 2.2.7.RELEASE.

It can be reproduced with a simple Spring Boot app created from Spring Initializr with options:

• Maven Project
• Java
• Spring Boot 2.3.0
• Packaging Jar
• Java 8
• No dependencies

The code to add are a Config class, @ActiveProfiles on the test class, and a application-test.properties file (empty contents).

Config class

package com.example.demo;

import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;

@Configuration
@PropertySource(
    ignoreResourceNotFound = false,
    value = "classpath:application-${spring.profiles.active}.properties")
public class Config {}

Test file with @ActiveProfiles

@SpringBootTest
@ActiveProfiles("test")
class DemoApplicationTests {

	@Test
	void contextLoads() {}
}

<!-- Thanks for raising a Spring Boot issue. Please take the time to review the following categories as some of them do not apply here.

🙅 "Please DO NOT Raise an Issue" Cases

• Question STOP!! Please ask questions about how to use something, or to understand why something isn't working as you expect it to, on Stack Overflow using the spring-boot tag.
• Security Vulnerability STOP!! Please don't raise security vulnerabilities here. Head over to https://pivotal.io/security to learn how to disclose them responsibly.
• Managed Dependency Upgrade You DO NOT need to raise an issue for a managed dependency version upgrade as there's a semi-automatic process for checking managed dependencies for new versions before a release. BUT pull requests for upgrades that are more involved than just a version property change are still most welcome.
• With an Immediate Pull Request An issue will be closed as a duplicate of the immediate pull request, so you don't have to raise an issue if you plan to create a pull request immediately.

🐞 Bug report (please don't include this emoji/text, just add your details) Please provide details of the problem, including the version of Spring Boot that you are using. If possible, please provide a test case or sample application that reproduces the problem. This makes it much easier for us to diagnose the problem and to verify that we have fixed it.

🎁 Enhancement (please don't include this emoji/text, just add your details) Please start by describing the problem that you are trying to solve. There may already be a solution, or there may be a way to solve it that you hadn't considered.

TIP: You can always edit your issue if it isn't formatted correctly. See https://guides.github.com/features/mastering-markdown -->

spring.profiles.include and spring.profiles are not used by the new config data code. However, they are still valid if legacy processing is switched on. We should consider if we want to deprecate them in the metadata.

We also need to update the documentation which mentions spring.profiles.include here.

According to the documentation:

Sometimes, it is useful to have profile-specific properties that add to the active profiles rather than replace them. The spring.profiles.include property can be used to unconditionally add active profiles.

The example in the documentation shows two included profiles that look to have mutually exclusive properties:

spring.profiles.include:
  - proddb
  - prodmq

As evidenced by this question, and this comment, the documentation is a bit ambiguous.

Let's add this extra information to the documentation:

What happens when the active profile has a property definition that is also defined in one of the included profiles?

application-foo.yaml

myCustomProperty: 10

application-bar.yaml

spring:
  profiles:
    include: foo
myCustomProperty: 20

In this case, foo wins and myCustomProperty = 10.

What happens when the included profiles do not have mutually exclusive property definitions?

application-x.yaml

myCustomProperty: 10

application-y.yaml

myCustomProperty: 20

application-z.yaml

spring:
  profiles:
    include: x, y

myCustomProperty: 30

In this, y wins and myCustomProperty = 20.

Also, IMHO, when the included profiles (e.g. x and y in the example above) have shared property definitions, a warning log message should be emitted as I think a situation like this is the sign of a potential misconfiguration by the user.

With the rewrite of config file and profile processing in 2.4.x, profiles can no longer be included in profile specific sub sections. All profiles need to be available before any profile-specific files/documents are loaded. This issue can be closed.

Environment

Spring-boot : 2.1.7.RELEASE OS : Ubuntu 16.04

From this issue #1219 :

After application is loaded, Setting spring.profile.default value seems it's not working.

You can't change the default profile by declaring it in a config file. It has to be in place before the config files are read.

However, when I pass a value in spring.profiles.default in application.properties, the spring-boot console shows

No active profile set, falling back to default profiles: dev

The weird thing is dev profile wasn't actually activated.

I would expect if the default profile have set it up in application.properties, the console should display :

No active profile set, falling back to default profiles: default

This is a duplicate of #15994 which has been solved in 2.4.x.

I believe that spring.profiles.default property does not work as documented.

Let's consider following two application property files:

application.properties: spring.profiles.default=profile1

application-profile1.properties: server.servlet.context-path=/foo

And corresponding application that simply prints server.servlet.context-path and profile values:

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        ApplicationContext ctx = SpringApplication.run(Application.class, args);
        System.out.println("Context-path: " + ctx.getEnvironment().getProperty("server.servlet.context-path"));
        System.out.println("active profiles: " + Arrays.asList(ctx.getEnvironment().getActiveProfiles()));
        System.out.println("default profiles: " + Arrays.asList(ctx.getEnvironment().getDefaultProfiles()));
    }
}

When run without parameters, I get:

Context-path: null active profiles: [] default profiles: [profile1]

When run with explicitly selecting profile1 on command line with --spring.profiles.active=profile1, I get:

Context-path: /foo active profiles: [profile1] default profiles: [profile1]

My expectation is that in the first (parameter-less) execution, context-path would be /foo because profile1 properties are loaded as default.

This should work with the changes we've made to processing of configuration files and profiles in 2.4.x.

The groups property will work with multiple property files as well. The groups need to be declared in the main application.properties file but profile specific properties can still be defined in profile-specific files. So you would have an application.properties with

spring.profiles.group.local=dev

and define other properties in application-local.properties and application-dev.properties.

Would it be possible there to import multiple configuration files?

Yes. spring.config.import can be a list.

Why is there not the possibility to just give the profile name, why has it to be the whole filename (which can be a lot longer than just profile?

The imports are not necessarily tied to active profiles. Several locations can be specified under a single spring.config.import key and not just files that look like application-dev.properties.

Will the other possibilities (spring.profiles.include) work along with the new property?

spring.profiles.include has been replaced by spring.profiles.group.* to activate additional profiles if the given profile is active. There were several issues with configuring spring.profiles.include in a profile-specific file/document and it would lead to unexpected results. This is why we require that all profile groups are declared in the main application.properties file (and not in a profile specific section/file) so that we can compute the profiles that are active before loading any profile specific sections.

Will this also work with yml files?

Yes!

A combination of spring.config.import for the dev properties, spring.profiles.group for activating additional profiles and multiple properties file should work for you. If not, please provide a minimal sample that demonstrates the use case that does not work.

I've following problem.

I've an instance with following active profiles: dev, test, foo

and apllication-test.yaml file

---
my.prop1: default
my.prop2: default
---
spring.profiles: dev
my.
    prop1: dev
    prop3: abc
---
spring.profiles: foo
my.prop2: foo

My intuition would tell me: my.prop1 = dev my.prop2 = foo

Thought the result is really: my.prop1 = default my.prop2 = foo

It seems to use the order of profiles, rather then the order of the document. This seems to be different then what the documentation is saying. (Correct me if I'm wrong)

Further more my.prop3 seems to be not set at all as if this section is ignored even if dev is set active.

Is this a bug of Spring or is there a trick to it?

lG Lukas

This should be solved by config data rewrite in 2.4.x. For multi-document files, later documents can override the properties defined in earlier ones. With the following configuration in application-test.yml and active profiles of dev, foo, test,

---
my.prop1: default
my.prop2: default
---
spring.profiles: dev
my.
    prop1: dev
    prop3: abc
---
spring.profiles: foo
my.prop2: foo

the result is

my.prop1 = dev my.prop2 = foo my.prop3 = abc

@kzwang We have overhauled processing of configuration files and profiles in 2.4.x. This should work as expected now with the 2.4.0-SNAPSHOTs. With multi-document files, later documents will override the properties defined in earlier ones. Could you give it a try with the latest snapshots and let us know if this works for you?

@aratnam86 With 2.4.x, we have added the concept of importing additional configuration files using the spring.config.import property. For your application, I can imagine an application.properties file that looks something like this:

#---
spring.config.activate.on-profile=dev
spring.config.import=pearl-services-dev.properties,ruby-services-dev.properties,diamond-service-dev.properties
#---
spring.config.activate.on-profile=prod
spring.config.import=pearl-services-prod.properties,ruby-services-prod.properties,diamond-service-prod.properties

For tests, you can add another application.properties file that imports the test specific configuration. The #--- syntax is also new in the 2.4.x line which is support for multi-document .properties files.

We've added support for importing additional files in the 2.4.x line so you can give it a try using the 2.4.0-SNAPSHOTs. For more details, please see the reference guide.

Could you let us know if this meets your needs and if not then please provide a minimal sample that we can run to understand the use case further.

That being said, if your code relies on reading the spring.profiles.active property, you should set it explicitly, using the properties attribute of @SpringBootTest, rather than relying on the implementation details of @ActiveProfiles.

@huehnerlady We have changed the way we process configuration files and profiles in 2.4.x. In this particular case, there are two options to get to the result you want.

1. We have introduced the concept of importing configuration files. If the only reason the dev profile was being activated was to load the application-dev.properties file, this can now be done with the spring.config.import property. For example, if there's some configuration that needs to be loaded when the local profile is active, it can be done by adding the following to application-local.properties:

spring.config.import=application-dev.properties (the name can even be something like developer.properties)

We have also added support for multi-document properties files. So if you prefer to use a single application.properties file instead of an additional application-local.properties file, it would look like this:

#---
spring.config.activate.on-profile=local
spring.config.import=application-dev.properties

2. If the dev profile needs to be active for reasons other than loading application-dev.properties, it can be done using profile groups in the main application.properties file as follows:

spring.profiles.group.local=dev
#---
spring.config.activate.on-profile=local
dev.overrides.local=false
#---
spring.config.activate.on-profile=dev
dev.overrides.local=true

The order in which profiles are added to the environment will be determined by the ordering of the documents. Later documents will override the properties defined in earlier ones.

For more details on the new processing options, please see the reference guide. Please let us know if these options work for you using the 2.4.0-SNAPSHOTs

Currently IncludeExcludeGroupMemberPredicate required a * if all groups are to be included. It would be nice if instead you could write:

management:
  endpoint:
    health:
      group:
        mygroup:
          exclude:
          - db

We should be using acceptedProfiles here.

@spencergibb We did a POC for spring-cloud-consul-config using a ConfigDataLocationResolver.

We should be using acceptedProfiles here.

Thanks @nebhale. This has now been merged into master with some changes.

This change updates the pipeline definition to polish it up a bit. It does some renaming and restructuring, but generally aims to increase parallelism and accuracy in success and failure situations.

[resolves #479]

Spring Boot version - 2.3.0 Dependencies - Spring Webflux, Spring Security

Using the spring.webflux.base-path in Webflux project with Spring Security, default authentication endpoint /login doesn't get prefixed with basepath provided, which results in 404 not found.

Steps to reproduce :

1. Add spring.webflux.base-path=/test in application.properties.
2. Request any endpoint, that will open Spring Security default login page.
3. Enter username as user and password provided in the console.
4. Submitting the form results in HTTP ERROR 404

Thanks @rwinch. I think we can close this issue in favor of the Spring Security fix.

I wasn't able to reproduce this with the servlet stack with spring.mvc.servlet.path set to /test. @scottfrederick and I chatted about it and it appears that there might have been with a different issue with his setup.

The issue still applies to Webflux. It seems to be happening because the login page that Spring Security generates does not take the base path into account. When the form is submitted, it results in a POST to /login which returns a 404. I don't think there's anything we can do in Spring Boot about this and that the fix for this would be in Spring Security but I would like to get thoughts from @bclozel and @rwinch.

Closing in favor of PR #480.

We have some unnecessary gets.

@wagnerluis1982 Thanks for offering to help but I'm not sure what the solution will look like. Unlike other health indicators, where the value used in the condition(https://github.com/spring-projects/spring-boot/blob/255f8197ab35a363283429173de9db5f0c7f5eb0/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/system/DiskSpaceHealthContributorAutoConfiguration.java#L38) matches the flag used to enable the indicator, management.health.diskspace.enabled, the probes one does not. This causes the condition to check the value of management.health.defaults.enabled. I will mark this for team attention to discuss it with the rest of the team and update the issue based on the result of that discussion.

@thenx-wei Thanks for making your first contribution to Spring Boot. This has now been merged into 2.2.x, 2.3.x and master.

Forward port of issue #22155 to 2.4.x.

Forward port of issue #22082 to 2.3.x.