Service name resolution using spring.application.name doesn't support multi-document properties

[vpavic]

Describe the bug

SpringBootServiceNameDetector supports resolving service name from application.properties but is not aware of Spring Boot's support for multi-document properties - see Working With Multi-Document Files section of Spring Boot's reference manual. Multi-document properties allow the same configuration property to be present multiple times inside application.properties and the actual resolved value is dependent on some condition, for example:

spring.main.banner-mode=off
#---
spring.config.activate.on-profile=product1
spring.application.name=product1-backend
#---
spring.config.activate.on-profile=product2
spring.application.name=product2-backend

With such application.properties, SpringBootServiceNameDetector will always resolve service name to product2-backend regardless of the currently active profile.

Relevant documentation does not mention this being a known limitation.

Note that this might also affect application.yaml but I didn't confirm.

Steps to reproduce

• any Spring Boot application with application.properties set up like above
• Java agent instrumentation without explicitly provided service name

Expected behavior

Resolved service name would be the one actually in use taking account conditions.

Actual behavior

Resolved service name doesn't take into account conditions and resolves service name from last occurrence of spring.application.name in application.properties.

Javaagent or library instrumentation version

v2.12.0

Environment

n/r

Additional context

n/a

[laurit]

Multi-document properties allow the same configuration property to be present multiple times inside application.properties and the actual resolved value is dependent on some condition

Agent needs to figure out the application name before any of the spring code is run so getting the application name from the spring properties/yaml is best effort. We can not fully replicate how spring does this. In contrast this should work with the spring starter as the starter can ask from spring for the value of spring.application.name.
I think the best option for this issue would be to update the documentation.