spring-cloud / spring-cloud/spring-cloud-config
Discovery setting can't set in a different profile when use Discovery First Lookup.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2k
- Forks
- 1.3k
- Avg merge
- 2d 59m
- Merged PRs (30d)
- 16
Description
Describe the bug
When I set discovery setting in specific profile(e.g. application-test.yml), it will raise an exception.
java.lang.NullPointerException: null
at org.springframework.cloud.config.client.ConfigServerInstanceProvider.getConfigServerInstances(ConfigServerInstanceProvider.java:57) ~[spring-cloud-config-client-3.1.0-RC1.jar:3.1.0-RC1]
at org.springframework.cloud.config.client.ConfigServerInstanceMonitor.refresh(ConfigServerInstanceMonitor.java:90) ~[spring-cloud-config-client-3.1.0-RC1.jar:3.1.0-RC1]
The bootstrapContext register Binder with activationContext after contributors process imports.
So in ConfigServerConfigDataLocationResolver#resolveProfileSpecific method, the bootstrapContext has no activationContext, and the resolverContext has activationContext.
Therefore, resolverContext resolved spring.cloud.config.discovery.enabled is true, However
bootstrapContext resolved result is false. It cause the ConfigServerInstanceProvider.Function register in EurekaConfigServerBootstrapper is null.
Sample
The configuration in application-test.yml
eureka:
client:
serviceUrl:
defaultZone: http://127.0.0.1:8761/eureka/
spring:
config:
import: 'optional:configserver:'
cloud:
config:
enabled: true
discovery:
enabled: true
serviceId: configserver
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at ConfigServerConfigDataLocationResolver#resolveProfileSpecific and compare the resolverContext and bootstrapContext activation contexts described in the report. Trace ConfigServerInstanceProvider#getConfigServerInstances, ConfigServerInstanceMonitor#refresh, and EurekaConfigServerBootstrapper. Done means the application-test.yml discovery settings no longer cause a NullPointerException and the discovery provider is available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring, spring-boot
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100