not expected splunk's otel contribution

[krismarc]

In v5, Splunk's OTEL contribiutes even if not expected.

That's most likely because of

java-buildpack/src/java/frameworks/splunk_otel_java_agent.go

Line 68 in 9ce86e2

vcapServices.HasServiceByNamePattern("otel") {

This causes additional java opt to be added that forces otel.service.name to be CF's app name, not the one set in otel's user-provided service payload. (both are present, however later one takes precedence)

java-buildpack/src/java/frameworks/splunk_otel_java_agent.go

Line 133 in 9ce86e2

opts = append(opts, fmt.Sprintf("-Dotel.service.name=%s", appName))

Ultimetly, if there's otel named user-provided service, both open-telemetry and splunk's otel contribiute and -Dotel.service.name is added twice with different values if otel.service.name is given in user-provided service payload.

java-buildpack/src/java/frameworks/open_telemetry_javaagent.go

Line 112 in 9ce86e2

if _, hasServiceName := service.Credentials["otel.service.name"]; !hasServiceName {

https://github.com/cloudfoundry/java-buildpack/blob/main/docs/framework-splunk_otel_java_agent.md

The service name MUST contain the string splunk-o11y.

..which is currently not really true

[krismarc]

#1134 probably related

[kiril-keranov]

Please note that in the ruby based implementation it could also happen having -Dotel.service.name=<app_name> twice if an app is bound to both otel-collector and splunk-o11y but the properties would have the same correct value. The condition vcapServices.HasServiceByNamePattern("otel") is now removed from splunk agent framework in order not to provoke unexpected splunk agent contribution and the condition on splunk-o11y is restored. Also the wrongly set app name in the otel agent framework is now fixed