profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/mbhave/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

mbhave/initializr-stats 5

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

Deprecate CommonOAuth2Provider.OKTA

I think CommonOAuth2Provider provides value for providers such as Facebook, Google and Github (if the URLs still work). For Okta, I agree with @Kehrlann and @jgrandja that there isn't much value add. For Facebook, Google and, Github, you can skip the provider configuration entirely if you don't want to customize anything. That's not the case with Okta and you need to either specifiy the authorization and token endpoints or the issuer uri. In fact, the one thing that it is defaulting, which is the scopes, is something we would rather have the user be explicit about. And once you have the provider configuration, adding scopes is just one more line in the properties. Given this, deprecating CommonOAuth2Provider.OKTA seems reasonable to me.

I like @rwinch's suggestion about renaming CommonOAuth2Provider to make it more obvious that it's oauth2Login specific, or at the very least updating the javadoc to say so.

jgrandja

comment created time in a day

issue openedspring-projects/spring-boot

Sanitize flattened VCAP_SERVICES properties

We sanitize vcap_services but CloudFoundryVcapEnvironmentPostProcessor converts them to vcap.services.* which should also be sanitized.

created time in 2 days

push eventspring-projects/spring-boot

Madhura Bhave

commit sha ef2a5daa590870e964643d5f2b913548e4cb6daa

Polish

view details

push time in 2 days

push eventspring-projects/spring-boot

Stephane Nicoll

commit sha 6c8c8502e3098f50ec3f21be0d79aad756e012e8

Log failing calls to health indicators Closes gh-22632 Co-authored-by: Madhura Bhave <bhavem@vmware.com>

view details

push time in 3 days

issue closedspring-projects/spring-boot

Log failing calls to health indicators

This is similar to #22509 to improve root cause analysis when probe endpoints returned non 200 response.

I am migrating k8s http probes to use readiness and liveness health group endpoints(/actuator/health/[readiness|liveness]). When these endpoints return non UP status(other than 200 response), k8s stops traffic or shutdown the pod. When such event happens, k8s http probe only record the returned http status for the reason of its probe failure. This makes hard to investigate WHY readiness/liveness probes returned non 200 response when somebody needs to investigate the failure reason later. Even if k8s could record body of probe response, it would be nicer to have such information in application log.

I wrote this implementation to our services to log information when health endpoints returns non UP response.

@Slf4j
public class LoggingHealthEndpointWebExtension extends HealthEndpointWebExtension {

	public LoggingHealthEndpointWebExtension(HealthContributorRegistry registry, HealthEndpointGroups groups) {
		super(registry, groups);
	}

	@Override
	public WebEndpointResponse<HealthComponent> health(ApiVersion apiVersion, SecurityContext securityContext,
			boolean showAll, String... path) {
		WebEndpointResponse<HealthComponent> response = super.health(apiVersion, securityContext, showAll, path);
		HealthComponent health = response.getBody();
		if (health == null) {
			return response;
		}

		Status status = health.getStatus();
		if (status != Status.UP) {
			Map<String, HealthComponent> components = new TreeMap<>();
			if (health instanceof CompositeHealth) {
				Map<String, HealthComponent> details = ((CompositeHealth) health).getComponents();
				if (details != null) {
					components.putAll(details);
				}
			}
			log.warn("Health endpoints {} returned {}. components={}", path, status, components);
		}

		return response;
	}

}

If HealthEndpointSupport could have logging capability (or HealthEndpointWebExtension and ReactiveHealthEndpointWebExtension for web only), then we don't need to have this custom implementation.

Something like:

boolean enableLogging;

if(this.enableLogging && health.getStatus() != Status.UP) {
  log.warn(...);
}

closed time in 3 days

ttddyy

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 7e257dc24c028c037af3fb77972a45f9e0f38b81

Rename packages for code samples to match sections See gh-27132

view details

Madhura Bhave

commit sha ac00df79f14486378f01343d99ff8ac78cc17292

Add what's next to new sections This commit also moves hazelcast from core features to IO Closes gh-27132

view details

push time in 3 days

issue closedspring-projects/spring-boot

Split spring boot features in reference documentation into smaller sections

  • [x] Add what's next to new sections
  • [x] Move hazelcast out of core features
  • [x] Rename packages for code samples to match sections

closed time in 3 days

mbhave

issue closedspring-projects/spring-boot

Allow more control over property overriding for profile-specific files

We have dev, int, and prod environments with matching profiles. These environments share a lot of the same configuration because these environments all live in AWS, so we also have an aws profile. We set spring.active.profiles to dev, int, or prod.

We're trying to use the spring.profiles.group feature:

# application.yaml
spring:
  profiles:
    group:
      dev: aws
      int: aws
      prod: aws

# application-aws.yaml
... # aws-specific configuration
# application-dev.yaml
... # dev-specific configuration

However, spring.profiles.group isn't meeting our needs. In this example, the aws profile will override the environment-specific profile. This overriding is undesirable because we believe that a more specific profile should override a more general profile.

We're aware of the following solutions, but we don't find them ideal either:

Multi-document files

Multi-document files would allow us to control override order by placing the environment-specific profiles at the bottom of the file. This placement would allow the environment-specific profiles to override the aws profile. However, we find multi-document files more difficult to read and maintain, but maybe we're just not used to multi-document files. We've noticed that much of the Spring Boot documentation uses multi-document files. Does Spring Boot encourage use of multi-document files over profile-specific files because multi-document files allow more control in overriding? Multi-document files would address our issue.

spring.active.profiles

We could set spring.active.profiles to aws,dev on application start-up, but ideally, we'd only have to set spring.active.profiles to dev. We also have other profiles, and setting all of these profiles in spring.active.profiles across many applications seems unnecessary.

spring.config.location

It looks like we could use spring.config.location to control override order, but this solution isn't ideal because we'd have to define spring.config.location as an environment property as required by Spring Boot. If we have to set an environment property, we may as well just use spring.active.profiles.

Include environment-specific profiles outside of our packaged JAR file

All of our profiles are packaged within the JAR file as part of our classpath. We don't want to also have to include our environment-specific profiles outside of our JAR files. We'd find it easier to use spring.active.profiles.

Potential solutions

Allow users to disable overriding and throw an exception if they attempt to set the same property twice

Obvious value exists in allowing properties outside of the packaged JAR file to override properties packaged inside the JAR file, but less value exists in property overriding within the JAR file. Users should have full control over application properties within the classpath, so why is property overriding necessary or desired? In many cases, users might unintentionally override their properties. If users could disable overriding for properties packaged inside the JAR file, property load order wouldn't matter.

Place environment-specific profiles in the classpath /config package and the AWS profile in the classpath root

Spring Boot documentation says that files in the classpath /config package should override files in the classpath root, but this functionality doesn't seem to work for us. Maybe because this functionality doesn't apply to profile-specific files or because this functionality doesn't apply to spring.profiles.group. If this functionality worked or a similar functionality existed, it would have an advantage in that we could separate our environment-specific profiles from our more general profiles. We also have other profiles, and it would make a lot of sense to group the environment-specific profiles (ci-cd, dev, int, prod, etc.) separately from the more general profiles (aws, etc.), such as placing them in separate directories.

closed time in 6 days

Slooz

issue commentspring-projects/spring-boot

Allow more control over property overriding for profile-specific files

I am going to close this issue because there is a solution that works. I don't think we can throw an exception if the same property is set in multiple files because there can be a valid reason to do depending on how profiles are activated.

Slooz

comment created time in 6 days

issue commentspring-projects/spring-boot

Spring boot Actuator env endpoint does not sanitize SPRING_APPLICATION_JSON by default

In 2.6.x, we might be able to make use of the support added in #27840 to sanitize data from the spring.application.json property source if the key matches the configured keysToSanitize or the default ones. However, given that this can expose potentially sensitive information, flagging for team meeting to see if we should do this on the other branches as well.

Choobz

comment created time in 6 days

create barnchmbhave/spring-boot

branch : gh-22632

created branch time in 6 days

PR closed spring-projects/spring-boot

log health status (and description) if status != UP status: waiting-for-feedback status: waiting-for-triage

It is important to not only know that a service is unhealthy, but also why it is (which health check, description). Unfortunately some external monitoring systems do not provide the output/body of the HTTP request or do not create a history of that. A simple log message solves the issue completely in these cases. For this reason I implemented a log statement in case the health check is not UP. To not change the default behavior and annoy people I choosed the DEBUG level.

I think that can be a useful feature for some people and does not harm anyone else.

btw: Its a bit unclear for me how you manage your branches. If this is merged into master, how will it be integrated best into 2.2.x and 2.3.x?

+17 -0

2 comments

2 changed files

jackhammer2k

pr closed time in 6 days

pull request commentspring-projects/spring-boot

log health status (and description) if status != UP

@jackhammer2k We have decided to use the approach suggested by @snicoll here by exposing an accessor for the exception on the builder. Thanks anyway and sorry for the wasted effort.

jackhammer2k

comment created time in 6 days

issue commentspring-projects/spring-boot

ReactiveOAuth2ClientAutoConfiguration should be used in Servlet environments

Thanks for the link above, @rwinch.

@chrylis I am not conflating the two. If I was, I would have closed this issue and not involved the team for further discussion.

Regarding this sentence

Spring Security 5 OAuth2 provides token-injection support only for WebClient (via the ServerOAuth2AuthorizedClientExchangeFilterFunction), not RestTemplate (as with the former OAuth2RestTemplate), and using that filter requires either a ReactiveOAuth2AuthorizedClientManager or ReactiveClientRegistrationRepository and ServerOAuth2AuthorizedClientRepository

from this comment, from what I can tell that isn't accurate. WebClient integration for Servlet environments can be configured via a ServletOAuth2AuthorizedClientExchangeFilterFunction, which requires either a OAuth2AuthorizedClientManager or ClientRegistrationRepository and OAuth2AuthorizedClientRepository. These are auto-configured by OAuth2ClientAutoConfiguration for servlet applications. This sample showcases how to configure OAuth2 for WebClient in servlet applications. Can you please clarify why this setup does not work for you?

chrylis

comment created time in 7 days

pull request commentspring-projects/spring-boot

Health indicators based on Service Level Objectives

@snicoll and I discussed this today. There are few things that came up:

  1. Since we decided that the diskspace health indicator should ideally be something that can be configured in the monitoring system, this feels very much along those lines. If we decide to surface the SLO's as a health indicator, we should align our strategy for diskspace accordingly. Even if the deprecation of the diskspace indicator, we could surface that information in health via the SLOs.
  2. We are not sure if having a top-level component for every SLO is the best way to do this. Maybe having some sort of nested structure for the SLOs might be a better alternative.
  3. From an API perspective, we could have an API to expose SLOs which we could use to create the composite rather than the current method which registers beans within a bean method.

Flagging for team-meeting so that we can discuss this on the next team call.

jkschneider

comment created time in 8 days

issue commentspring-projects/spring-boot

ReactiveOAuth2ClientAutoConfiguration should be used in Servlet environments

I'm not sure I follow this question because I'm not sure what specifically variants is referring to.

It's referring to switching on the beans configured both by ReactiveOAuth2ClientAutoConfiguration and OAuth2ClientAutoConfiguration. But, I don't think that would make a difference because the beans configured by ReactiveOAuth2ClientAutoConfiguration are only used in a webflux application, as @jgrandja pointed out, and the beans auto-configured by OAuth2ClientAutoConfiguration are only used in a servlet environment.

The WebClient APIs allow for attributes to be passed in but RestTemplate does not. The OAuth features rely on the attributes.

@rwinch Given this, what is the best way to use WebClient for OAuth2 requests in a servlet application?

chrylis

comment created time in 8 days

issue commentspring-projects/spring-boot

ReactiveOAuth2ClientAutoConfiguration should be used in Servlet environments

@jgrandja @rwinch Could you provide more insight into points 3 and 4 from Brian's comment, please?

chrylis

comment created time in 9 days

issue commentspring-projects/spring-boot

Issue with recording metrics for exceptions thrown from filters

This issue added the second catch block. I think we set the status in the first catch in anticipation of what the servlet container would do if the exception got to it. This way we can match the status code in the metric to the status code of the actual response. I am not sure why we don't do that in the second catch as well. Flagging for team attention to get the rest of the team's thoughts.

There's another issue related to handling of the 500 response status, although it is slightly different.

tmachows

comment created time in 9 days

issue commentspring-projects/spring-boot

Allow more control over property overriding for profile-specific files

Thanks for the example, @Slooz.

If classpath:/config/ files should always override classpath:/ files, then the dev profile's info logging level should override the aws profile's warn logging level, but Spring Boot uses the warn logging level.

This is not the case because, by default, classpath:/ and classpath:/config/ are considered to be part of the same "location group". There is an example of how a location group is processed here.

Slooz

comment created time in 9 days

GollumEvent

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 393081f2e6a590df71cdef94e66c5996bbcc44ed

Enable PathPattern based matching for MVC actuators Closes gh-24645

view details

push time in 15 days

issue closedspring-projects/spring-boot

Enable PathPattern based matching for MVC actuators

Spring Framework 5.3 introduced the PathPattern as an efficient alternative to AntPathMatcher URL matching. Spring Boot 2.4 introduced (in issue #21694) a new config property to enable the PathPattern-based URL matching; spring.mvc.pathmatch.matching-strategy=path_pattern_parser.

This works well for URL matching of @Controllers etc, but org.springframework.boot.actuate.endpoint.web.servlet.WebMvcEndpointHandlerMapping does not respect the aforementioned config property - it always uses the AntPathMatcher-based URL matching. I.e. all actuator endpoints still have their URLs matched with AntPathMatcher. This is a bit painful since the WebMvcEndpointHandlerMapping typically has higher priority than the RequestMappingHandlerMapping and hence is asked to try to match every incoming request before the RequestMappingHandlerMapping gets to do its thing. I.e. every request is still matched with the AntPathMatcher even if we use spring.mvc.pathmatch.matching-strategy=path_pattern_parser.

I would expect the WebMvcEndpointHandlerMapping to respect the configuration and use the PathPattern-based URL matching in this case so that I can completely eliminate the use of AntPathMatcher.

The root cause of this seems to be that WebMvcEndpointHandlerMapping initialises its AbstractWebMvcEndpointHandlerMapping#builderConfig via a private static method that does not take any configuration into account.

In contrast RequestMappingHandlerMapping (that respects the configuration property) initialises RequestMappingHandlerMapping#config in #afterPropertiesSet() with the pattern parser typically injected via org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter#configurePathMatch.

closed time in 15 days

tommyk-gears

create barnchmbhave/spring-boot

branch : gh-24645

created branch time in 15 days

issue commentspring-projects/spring-boot

ConditionalOnClass not working for Bean methods on Java 8

Thanks for the suggestion. I think we should update the javadoc.

filiphr

comment created time in 20 days

push eventspring-projects/spring-boot

Madhura Bhave

commit sha 2d89a8253cf4fc23dee831256a75730fcbba68d9

Switch default MVC path matching strategy" Change the default `spring.mvc.pathmatch.matching-strategy` to `PATH_PATTERN_PARSER`. Closes gh-24805

view details

push time in 22 days

issue closedspring-projects/spring-boot

Switch default spring.mvc.pathmatch.matching-strategy

We could upgrade to the new PathPattern based solution now.

closed time in 22 days

philwebb

issue commentspring-projects/spring-boot

ConditionalOnClass not working for Bean methods on Java 8

The javadoc for @ConditionalOnClass calls out being extra careful when placing it on a @Bean method. See also Andy's comment in a previous issue. I think based on that there is nothing that we can do in Spring Boot. Leaving the issue open to get the team's thoughts.

filiphr

comment created time in 23 days

GollumEvent
GollumEvent

issue commentspring-projects/spring-boot

Allow more control over property overriding for profile-specific files

@Slooz Maybe something like this could work

spring:
  profiles:
    group:
      dev: aws,development
      int: aws,integration
      prod: aws,production

Then when the dev profile is active, application-development.yml would take precedence over application-aws.yml.

I am also not sure why classpath:/config/ doesn't work for you. If you could provide a small sample that replicates that, that would be helpful.

Slooz

comment created time in 23 days