Issue while resolving "spring.zipkin.service.name" because of "default" in SPeL

[sumeetmondal]

Issue
Sleuth Autoconfig sets value for service name as "default" even if we set the value in application.properties using spring.zipkin.service.name (value of spring.application.name is also not set)

Scenario:
The issue occurs when we have a "properties" file in one of the third party dependency jar, and we mention value of spring.zipkin.service.name in project's application.properties.

Analysis:
Spring follows a particular order of property value resolution as mentioned here.By default, spring will take a higher order of application-{profile}.properties in third party jar than application.properties in project. Incase, it's not available in the first matching property file, the SPeL sets it to "default".

In the above mentioned scenario, if the first property file (application-{profile}.properties file in a third party jar) does not include this property, TraceAutoConfiguration.java sets the value to "default". Now, since the value is set (i.e. default), spring will not bother to override it even if mentioned in any of the other property in the subsequent order list.
This issue happens because of the SPeL mentioned in

${spring.zipkin.service.name:${spring.application.name:default}}

Workaround
Override the Order application.properties of by a code like this, but this may consequence depending on the project

    @Bean
    public static PropertyPlaceholderConfigurer applicationPropConfig() {
        PropertyPlaceholderConfigurer ppc = new PropertyPlaceholderConfigurer();
        ppc.setLocations(new ClassPathResource("application.properties"));
        ppc.setOrder(Ordered.HIGHEST_PRECEDENCE);
        ppc.setIgnoreUnresolvablePlaceholders(true);
        return ppc;
    }

Suggestion
I think we should change the SPeL to a "ConfigurationProperty file" or something.
Tested on version Version 2.1.1.RELEASE.

Ref: issue discussion in spring framework (Unresolved, bulk closed early '19): spring-projects/spring-framework#14623

[ryanjbaxter]

This doesnt seem like an issue specific to sleuth, can you replicate this issue in a simple boot application? If so this should be filed to Spring Boot.

[sumeetmondal]

Yes, agree this issue belongs to spring boot. There is an issue already for this spring-projects/spring-framework#14623 but it seems like it will not be taken up due to too much refactoring required. Hence, I thought something can changed in sleuth to fix it.

[marcingrzejszczak]

This has to be fixed in boot