profile
viewpoint

mbhave/initializr-stats 4

Companion apps fo Efficient Web Applications with Spring Boot 2

cf-identity/concourse 0

BOSH Release

cf-identity/notifications 0

The notifications service component of CloudFoundry

issue commentspring-projects/spring-boot

Consider "leaf only" configtree imports

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.
philwebb

comment created time in a month

push eventspring-projects/spring-boot

Madhura Bhave

commit sha bbbbe8e4d28b1a355fa055aa1425602aca20e946

Make security auto-configs back off when SecurityFilterChain present Closes gh-22739

view details

push time in a month

issue closedspring-projects/spring-boot

Disable default security configuration when SecurityFilterChain bean is present

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.

closed time in a month

eleftherias

issue commentspring-projects/spring-boot

Disable default security configuration when SecurityFilterChain bean is present

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.

eleftherias

comment created time in a month

issue commentspring-projects/spring-boot

Empty map from higher order property source does not override non-empty map

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

mbhave

comment created time in a month

push eventspring-projects/spring-boot

Madhura Bhave

commit sha cdbb7f441a1f25eba7a4369b975e4600b1329904

Do not ignore null/empty values from SPRING_APPLICATION_JSON Fixes gh-21542

view details

Madhura Bhave

commit sha eeca767c49c5c89e59971acc04d07cefa3194953

Merge branch '2.2.x' into 2.3.x Closes gh-22895

view details

Madhura Bhave

commit sha 4799b26d2c25cb6a7a2dbb8ed2a66ed70b5e0887

Merge branch '2.3.x' Closes gh-22897

view details

push time in a month

issue closedspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

Forward port of issue #22895 to 2.4.x.

closed time in a month

mbhave

issue closedspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

Forward port of issue #21542 to 2.3.x.

closed time in a month

mbhave

issue closedspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

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.

closed time in a month

rgordeev

issue openedspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

Forward port of issue #22895 to 2.4.x.

created time in a month

push eventspring-projects/spring-boot

Madhura Bhave

commit sha cdbb7f441a1f25eba7a4369b975e4600b1329904

Do not ignore null/empty values from SPRING_APPLICATION_JSON Fixes gh-21542

view details

Madhura Bhave

commit sha eeca767c49c5c89e59971acc04d07cefa3194953

Merge branch '2.2.x' into 2.3.x Closes gh-22895

view details

push time in a month

issue openedspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

Forward port of issue #21542 to 2.3.x.

created time in a month

push eventspring-projects/spring-boot

Madhura Bhave

commit sha cdbb7f441a1f25eba7a4369b975e4600b1329904

Do not ignore null/empty values from SPRING_APPLICATION_JSON Fixes gh-21542

view details

push time in a month

issue commentspring-projects/spring-boot

Externalized Configuration ignores null values in SPRING_APPLICATION_JSON

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.

rgordeev

comment created time in a month

issue openedspring-io/start.spring.io

Setup notifications if the deployed code does not match the latest commit

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.

created time in a month

push eventspring-io/start.spring.io

Madhura Bhave

commit sha 7de6dea2cc2c9bbe467336b31d6af26a3ece6159

Revert to Spring Boot 2.3.1 It seems that this regression in 2.3.2 causes the liveness endpoint to 404: https://github.com/spring-projects/spring-boot/issues/22562 and the app goes in a crash loop

view details

push time in a month

issue commentspring-projects/spring-boot

Switching default to include layers index for fat jar

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.

mbhave

comment created time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha f39f33bb8d13c29ca3e72b1efbea60d0587ad997

Fix documentation related to the health endpoint's inner details Closes gh-22490

view details

Madhura Bhave

commit sha 3f82ca40e2dc9ac7414764e409e0bcff5fa67113

Merge branch '2.2.x' into 2.3.x Closes gh-22774

view details

Madhura Bhave

commit sha 6d82e9e97f0f650dbd23236cc490eaf8893950a8

Merge branch '2.3.x' Closes gh-22775

view details

push time in 2 months

issue closedspring-projects/spring-boot

Docs say Health's inner `details` section may contain components

Forward port of issue #22774 to 2.4.x.

closed time in 2 months

mbhave

issue closedspring-projects/spring-boot

Docs say Health's inner `details` section may contain components

Forward port of issue #22490 to 2.3.x.

closed time in 2 months

mbhave

issue closedspring-projects/spring-boot

Docs say Health's inner `details` section may contain components

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

closed time in 2 months

derekm

issue openedspring-projects/spring-boot

Docs say Health's inner `details` section may contain components

Forward port of issue #22774 to 2.4.x.

created time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha f39f33bb8d13c29ca3e72b1efbea60d0587ad997

Fix documentation related to the health endpoint's inner details Closes gh-22490

view details

Madhura Bhave

commit sha 3f82ca40e2dc9ac7414764e409e0bcff5fa67113

Merge branch '2.2.x' into 2.3.x Closes gh-22774

view details

push time in 2 months

issue openedspring-projects/spring-boot

Docs say Health's inner `details` section may contain components

Forward port of issue #22490 to 2.3.x.

created time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha f39f33bb8d13c29ca3e72b1efbea60d0587ad997

Fix documentation related to the health endpoint's inner details Closes gh-22490

view details

push time in 2 months

IssuesEvent

issue commentspring-projects/spring-boot

spring.profiles.active incorrect override

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

NKozlov

comment created time in 2 months

issue closedspring-projects/spring-boot

spring.profiles.active incorrect override

<!-- 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?

closed time in 2 months

NKozlov

issue commentspring-projects/spring-boot

spring.profiles.active incorrect override

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.

NKozlov

comment created time in 2 months

issue closedspring-projects/spring-boot

Improve logging for release promotion

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

closed time in 2 months

mbhave

issue commentspring-projects/spring-boot

Improve logging for release promotion

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

mbhave

comment created time in 2 months

issue commentspring-projects/spring-boot

Add bootstrap.yml to filtered resources

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

joelroyer

comment created time in 2 months

issue closedspring-projects/spring-boot

Add bootstrap.yml to filtered resources

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

closed time in 2 months

joelroyer

push eventspring-projects/spring-boot

Madhura Bhave

commit sha f0ef47dfadb36e82f0ddac4c012cc2056bb84439

Fix additional deprecations

view details

push time in 2 months

issue commentspring-projects/spring-boot

Disable default security configuration when SecurityFilterChain bean is present

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

eleftherias

comment created time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 5f386e456b6c99603d21613fdc58b50ba0fa5fb4

Fix test

view details

Madhura Bhave

commit sha 0d79bd08a6716991d7be9acbbf7a5772f9d1226a

Fix deprecations

view details

push time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha b9abcf1615f30c7da0c778b46a2a8435e0baab2c

Fail hard if spring.profiles.include is used with new config processing Closes gh-22693

view details

push time in 2 months

issue closedspring-projects/spring-boot

Fail hard if spring.profiles.include is used with new config processing

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.

closed time in 2 months

mbhave

issue closedspring-projects/spring-boot

Consider what to do about environment variable clashes

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?

closed time in 2 months

ghost

issue commentspring-projects/spring-boot

Consider what to do about environment variable clashes

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

ghost

comment created time in 2 months

issue closedspring-projects/spring-boot

Internal profile-specific properties override external non-profile-specific properties

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).

closed time in 2 months

bjfr

issue commentspring-projects/spring-boot

Internal profile-specific properties override external non-profile-specific properties

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.

bjfr

comment created time in 2 months

issue closedspring-projects/spring-boot

Tests with ActiveProfiles annotation cannot resolve placeholder 'spring.profiles.active'

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() {}
}

closed time in 2 months

andrewdroz

push eventspring-projects/spring-boot

Madhura Bhave

commit sha b14bd453993eff28608ff06db10d608c524e978f

Fix syntax for slack notification See gh-22709

view details

Madhura Bhave

commit sha 43c0b3d4dc434c6cfdc6644791c642ab12679ed5

Merge branch '2.2.x' into 2.3.x

view details

Madhura Bhave

commit sha d0507ac2f0f5804bb778c464fa14ff27a22ba32f

Merge branch '2.3.x'

view details

push time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha b14bd453993eff28608ff06db10d608c524e978f

Fix syntax for slack notification See gh-22709

view details

Madhura Bhave

commit sha 43c0b3d4dc434c6cfdc6644791c642ab12679ed5

Merge branch '2.2.x' into 2.3.x

view details

push time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha b14bd453993eff28608ff06db10d608c524e978f

Fix syntax for slack notification See gh-22709

view details

push time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 41f5ba9077f01b16a3c6fd0b543ddbac566f7e2f

Switch layering on by default Closes gh-20983

view details

push time in 2 months

issue closedspring-projects/spring-boot

Switching default to include layers index for fat jar

<!-- 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 -->

closed time in 2 months

mbhave

issue openedspring-projects/spring-boot

Consider marking properties related to legacy config file processing as deprecated

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.

created time in 2 months

issue closedspring-projects/spring-boot

Improve/disambiguate the documentation for spring.profiles.active

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.

closed time in 2 months

behrangsa

issue commentspring-projects/spring-boot

Improve/disambiguate the documentation for spring.profiles.active

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.

behrangsa

comment created time in 2 months

issue closedspring-projects/spring-boot

Different default profiles are used for loaded profile-specific configuration and for enabling profile-specific beans when spring.profile.default is configured in a config file

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

closed time in 2 months

Minwoo-Kang

issue closedspring-projects/spring-boot

Consider spring.profiles.default when processing configuration files

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.

closed time in 2 months

janotav

issue commentspring-projects/spring-boot

Consider spring.profiles.default when processing configuration files

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

janotav

comment created time in 2 months

issue commentspring-projects/spring-boot

Change order of spring-profiles using spring.profiles.include and active profiles

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.

huehnerlady

comment created time in 2 months

issue closedspring-projects/spring-boot

application-{$profile} yaml, reading order is weird

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

closed time in 2 months

LProemer

issue commentspring-projects/spring-boot

application-{$profile} yaml, reading order is weird

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

LProemer

comment created time in 2 months

issue commentspring-projects/spring-boot

Inconsistent configuration ordering with profiles

@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?

kzwang

comment created time in 2 months

issue commentspring-projects/spring-boot

Tests with ActiveProfiles annotation cannot resolve placeholder 'spring.profiles.active'

@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.

andrewdroz

comment created time in 2 months

issue commentspring-projects/spring-boot

Change order of spring-profiles using spring.profiles.include and active profiles

@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
  1. 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

huehnerlady

comment created time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 4b2c94cb2ba7ea273872eb929470c4e53bcb9625

Allow exclude only health groups Closes gh-22053

view details

push time in 2 months

issue closedspring-projects/spring-boot

Allow exclude only health groups

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

closed time in 2 months

philwebb

create barnchmbhave/spring-boot

branch : gh-20983

created branch time in 2 months

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 8d70010fce3e6295c821f9ca314ff76def74a550

Add expanded profile groups to environment Fixes gh-22605

view details

push time in 2 months

issue closedspring-projects/spring-boot

Profile groups are not applied to the environment

We should be using acceptedProfiles here.

closed time in 2 months

mbhave

issue commentspring-projects/spring-boot

Allow for programatic access to new ConfigDataEnvironment processing.

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

spencergibb

comment created time in 2 months

create barnchmbhave/spring-boot

branch : gh-22605

created branch time in 2 months

issue openedspring-projects/spring-boot

Profile groups are not applied to the environment

We should be using acceptedProfiles here.

created time in 2 months

push eventspring-io/start.spring.io

Madhura Bhave

commit sha 50bda22bb98915322f9983f41bae4795d465656f

Use unique build name for start-site pipeline Previously, it used the same build name as the initializr pipeline which would cause the pipeline to produce a file not found since the artifactory resource did not contain the right artifacts.

view details

push time in 2 months

create barnchmbhave/spring-boot

branch : configv2

created branch time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 400e31c2450ddb70c54d626494ca5734dbbad8da

Add more tests

view details

push time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 172fdb8965d80fa77987b2e074c2b5c53e8fc54e

Fix tests

view details

push time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha c5ff8341c84f82db0e52ca112edab3325fd24f48

Fixes

view details

push time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 7a15fe1c059a0bce230043474a58984f57a5f8ff

Fix tests

view details

push time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 551f59e75d6ced63d0b462b336d6cb4e8f26f552

Add integration tests

view details

push time in 2 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 9a79cddbd4b190172295f8dc4b3898514e4e0f8a

Hacking

view details

push time in 3 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 379905710504d39d3c3c4a423c255809eb65f197

Hacking

view details

push time in 3 months

pull request commentspring-io/start.spring.io

Polishing

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

nebhale

comment created time in 3 months

push eventspring-io/start.spring.io

Ben Hale

commit sha e7ee851f3a6ae4b99646c8e21925223b88aa7bb0

Polish pipeline.yml 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. See gh-480

view details

Madhura Bhave

commit sha 686a77513c724c0b0b444afcf885bd3d7186c1ed

Polish "Polish pipeline.yml" See gh-480

view details

Madhura Bhave

commit sha c50608f0d2663e86785bad885ddeac9417ec5aca

Merge pull request #480 from nebhale * pr/480: Polish "Polish pipeline.yml" Polish pipeline.yml Closes gh-480

view details

push time in 3 months

PR closed spring-io/start.spring.io

Polishing type: task

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]

+226 -175

0 comment

1 changed file

nebhale

pr closed time in 3 months

issue closedspring-projects/spring-boot

2.3.0 Webflux basepath property 'spring.webflux.base-path' with Spring Security default login page results in 404

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

closed time in 3 months

anupam-contaque

issue commentspring-projects/spring-boot

2.3.0 Webflux basepath property 'spring.webflux.base-path' with Spring Security default login page results in 404

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

anupam-contaque

comment created time in 3 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 3c1ae110f9f0edfc941595566aa95c6ca490131d

Hacking

view details

push time in 3 months

issue commentspring-projects/spring-boot

2.3.0 Webflux basepath property 'spring.webflux.base-path' with Spring Security default login page results in 404

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.

anupam-contaque

comment created time in 3 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha 08581da698cc8d955e577e3523ec06f5e8e4c6bf

Hacking

view details

push time in 3 months

push eventphilwebb/spring-boot

Madhura Bhave

commit sha b6c7a744c5ca5826aab694c931cfb30be032d910

Hacking

view details

push time in 3 months

push eventmbhave/spring-boot

Madhura Bhave

commit sha 79cdcfe154ebcc3f4e3ac1093812f4d16b83c03f

Hacking

view details

push time in 3 months

push eventmbhave/spring-boot

Madhura Bhave

commit sha b78c1da9a37245241afecf44b2ad2b2385281d81

Hacking

view details

push time in 3 months

create barnchmbhave/spring-boot

branch : config-v2

created branch time in 3 months

issue commentspring-io/start.spring.io

Polish pipeline.yml

Closing in favor of PR #480.

mbhave

comment created time in 3 months

issue closedspring-io/start.spring.io

Polish pipeline.yml

We have some unnecessary gets.

closed time in 3 months

mbhave

issue commentspring-projects/spring-boot

Liveness/Readiness probes returning 404 when health defaults are overriden

@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.

FlinnBurgess

comment created time in 3 months

pull request commentspring-projects/spring-boot

Simplify logic in ErrorPage's equals method

@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.

thenx-wei

comment created time in 3 months

push eventspring-projects/spring-boot

May

commit sha c1b9d3c2260d3c5bae733067da4f4d5ac1783e5f

Simplify logic in ErrorPage's equals method See gh-22082

view details

Madhura Bhave

commit sha 9c732fa2b632e8c4c047981d1179c3e474954a6f

Merge pull request #22082 from thenx-wei * pr/22082: Simplify logic in ErrorPage's equals method Closes gh-22082

view details

Madhura Bhave

commit sha f19f2b8714eb35975b5144db8bad56ad4caef835

Merge branch '2.2.x' into 2.3.x Closes gh-22155

view details

Madhura Bhave

commit sha 255f8197ab35a363283429173de9db5f0c7f5eb0

Merge branch '2.3.x' Closes gh-22156

view details

push time in 3 months

issue closedspring-projects/spring-boot

Simplify logic in ErrorPage's equals method

Forward port of issue #22155 to 2.4.x.

closed time in 3 months

mbhave

issue closedspring-projects/spring-boot

Simplify logic in ErrorPage's equals method

Forward port of issue #22082 to 2.3.x.

closed time in 3 months

mbhave
more