Launch Darkly Metrics conflating Version numbers. about java-server-sdk HOT 3 CLOSED

Even if the Java SDK wanted to put your application version in a header, it has no way by itself of knowing what that version is. I can only imagine that you are providing it somehow. The version string it puts in the User-Agent header by default, in that same piece of logic that you linked to above, is baked into the SDK (it comes from a constant in the source code which we update when we do an SDK release)— it is not inspecting jars in your classpath or anything like that.

Are you doing anything in your configuration to explicitly tell the SDK to use custom header values (like, with HttpConfigurationBuilder methods? Or, do you have any kind of proxy/gateway that might be rewriting HTTP headers?

from java-server-sdk.

It would appear that many of our services are still on older releases. I believe the logic for versioning was a little more naive then.

It appears that it's pulling the version off our our apps manifest. This was for v4.9.1.

Our app manifest looks something like.
Manifest-Version=1.0 Implementation-Version=0.1.0-dev.3221.uncommitted+c86a911 Built-Status=integration

from java-server-sdk.

Yes, and the possibility of something like that happening is why we stopped doing it that way. The change was described in the changelog for the 5.0.0 release as "LDClient.version() previously could not be used if the SDK classes were not packaged in their original jar. It now works correctly regardless of deployment details." The version string in the User-Agent header is provided by the same logic.

Unfortunately I don't think it's likely that there will be a patch for this in a 4.x version. Version 4.9.1 is more than two years old, and even the last minor version 4.14.x is already out of support per our end of life policy.

from java-server-sdk.