In my application, there has been a eureka registration application called unknown, through the tracking code found in the following ways.
org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(String)
public String resolveEmbeddedValue(String value) {
String result = value;
for (StringValueResolver resolver : this.embeddedValueResolvers) {
if (result == null) {
return null;
}
result = resolver.resolveStringValue(result);
}
return result;
}
When not the first position in the embeddedValueResolvers list to get the configuration value, the default value of unknown using the ${spring.application.name:unknown} configuration, access to the configuration value even in the list of embeddedValueResolvers, but the incoming key has changed.
Have you tried setting spring.application.name? http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html#_registering_with_eureka
Application.yml path of the classpath file configuration is as follows:
spring.application.name=uxunesbapt
#port
server.port=9089
#ip
eureka.instance.preferIpAddress= true
#check health
eureka.healthcheck.enabled=true
eureka.client.serviceUrl.defaultZone=http\://10.64.2.154\:7001/eureka/
eureka.client.registerWithEureka=true
eureka.client.fetchRegistry= true
feign.httpclient.enabled= false
feign.hystrix.enabled= false
This is a very basic part of spring cloud. You'll need to supply a sample project that recreates the problem.
Sample project :https://github.com/zlongyue/sxp.egs.git
please set the parameter of eureka.client.serviceUrl.defaultZone in the application.yml to the real address of eureka server
Thanks for the sample. It certainly reproduces the problem, and it looks like the addition of @EnableSwagger2 causes the problem to show up.
Your analysis of where the problem is seems to be right. @EnableSwagger2 adds an additional StringValueResolver. This new resolver resolves spring.application.name to UNKNOWN. In the next iteration of the for loop the resolver that would know how to resolve spring.application.name gets called but is passed result which is UNKNOWN and no longer contains the value to resolve.
As a work around you can set eureka.instance.appName to ${spring.application.name}.
Another workaround is to set the springfox-swagger* deps versions to 2.5.0
@alebar what actually changed in that release that helps?
@ryanjbaxter I have no idea. I've just changed the version as a quick fix after fighting with this bug for a two days. It worked so I left office in peace :)
@ryanjbaxter I wonder if rather than using @Value we set defaults in the creation of the @Bean? We do this in EurekaClientAutoConfiguration and the value can still be customized.
@spencergibb I was debugging that class today and I found that at the time of creation the EurekaInstanceConfigBean the nonSecurePort variable's value differs from port number that is returned from this.env.resolvePlaceholders("${server.port:${SERVER_PORT:${PORT:8080}}}"). That was the direct cause of registering my app in eureka with bad port number (and btw with bad appName too).
I also think that your suggestion of not using @Value may be the right way to go here.
@spencergibb worth a shot, I will take a look
By tracing found that in the SwaggerCommonConfiguration Swagger2.6, the PropertyPlaceholderConfigurer bean is an instance of the PropertySourcesPlaceholderConfigurer after the problem to solve the problem.
Problem code
@Bean
public static PropertyPlaceholderConfigurer swaggerProperties() {
PropertyPlaceholderConfigurer propertiesPlaceholderConfigurer = new PropertyPlaceholderConfigurer();
propertiesPlaceholderConfigurer.setIgnoreUnresolvablePlaceholders(true);
return propertiesPlaceholderConfigurer;
}
Modified normal code
@Bean
public static PropertySourcesPlaceholderConfigurer swaggerProperties() {
PropertySourcesPlaceholderConfigurer propertiesPlaceholderConfigurer = new PropertySourcesPlaceholderConfigurer();
propertiesPlaceholderConfigurer.setIgnoreUnresolvablePlaceholders(true);
return propertiesPlaceholderConfigurer;
}
hi, it is because you should have 2 configuration files: boostrap.yml with only the spring.application.name and the other application.yml, this last with all configuration about the implementaion lika database connections, swagger conf, etc...
Most helpful comment
hi, it is because you should have 2 configuration files: boostrap.yml with only the spring.application.name and the other application.yml, this last with all configuration about the implementaion lika database connections, swagger conf, etc...