detect service.name based on build-info.properties

[zeitlinger]

Add new resource provider SpringBootBuildInfoServiceNameDetector.

[jeanbisutti]

The current documented bhavior is

Could you please document the new proposed behavior somewhere for discussion in the next Java SIG meeting?

[zeitlinger]

Could you please document the new proposed behavior somewhere for discussion in the next Java SIG meeting?

added to this PR

[jeanbisutti]

Could you please document the new proposed behavior somewhere for discussion in the next Java SIG meeting?

added to this PR

The build-info.properties file seems always generated when the Spring Boot Maven/Gradle plugin creates an executable JAR:

build.artifact=spring-petclinic
build.encoding.reporting=UTF-8
build.encoding.source=UTF-8
build.group=org.springframework.samples
build.java.source=17
build.java.target=17
build.name=petclinic
build.time=2023-05-10T07\:42\:50Z
build.version=3.1.0-SNAPSHOT

It could be used instead of the detector based on the JAR file name, and the version may ne deduced from build.version.

Another option may be to use the manifest file.

[zeitlinger]

The build-info.properties file seems always generated when the Spring Boot Maven/Gradle plugin creates an executable

no, you have to trigger that explicitly

springBoot {
  buildInfo {
  }
}

It could be used instead of the detector based on the JAR file name, and the version may ne deduced from build.version.

yes, that's why I'm proposing to downgrade the priority of the jar detector: #10523

Another option may be to use the manifest file.

If you want to do something manually, I'd suggest to use otel.resource.attributes

[jeanbisutti]

no, you have to trigger that explicitly

springBoot {
  buildInfo {
  }
}

I am surprised. I have tested with the Spring Boot Maven plugin and the build info file is generated without any additional configuration.

[jeanbisutti]

no, you have to trigger that explicitly

springBoot {
  buildInfo {
  }
}

I am surprised. I have tested with the Spring Boot Maven plugin and the build info file is generated without any additional configuration.

Agree for Maven

[zeitlinger]

I am surprised. I have tested with the Spring Boot Maven plugin and the build info file is generated without any additional configuration.

My bad - the smoke test runs without this as well.

[jeanbisutti]

Could you please fix the merge conflict?

[zeitlinger]

Could you please document the new proposed behavior somewhere for discussion in the next Java SIG meeting?

open-telemetry/opentelemetry.io#3999

[zeitlinger]

@jeanbisutti can you review? (I know we talked about it, but I don't remember if anything needs to be done)

[zeitlinger]

I added an integration test now (smoke test), which is not a spring starter test.
I couldn't figure out why it fails - the build-info file is generated correctly.

[zeitlinger]

I added an integration test now (smoke test), which is not a spring starter test. I couldn't figure out why it fails - the build-info file is generated correctly.

Now I got it - the smoke test image is referred to by a tag - so it's not using the image generated in the current build.

[jeanbisutti]

e smoke test image

The smoke tests based on a Docker image are used to test the Java agent, not the OpenTelemetry Spring starter.

[jeanbisutti]

Cold you please explain the removal of this line?

[zeitlinger]

this is a test file that is supposed to not find the expected entry.
Before, it did not have build.version - and now it also must not have build.name.

[jeanbisutti]

I would need to verify it works with GraalVM.

[jeanbisutti]

I'd rather avoid inheritance and do composition. But it's not a blocker for this case that keeps simple.

[zeitlinger]

yes, that's a good point - wdyt about using the mechanism from #10621 ?

[jeanbisutti]

For my point of view it could be great, but only for new classes.

[zeitlinger]

is outdated now - re-open if needed