Compatibility with Spring Boot 2.4 and Spring Cloud Sleuth 3.x

[chadlwilson]

Does this work with Spring Boot 2.4 and Sleuth 3?

In any case, it'd be great to get a comment in the readme on compatibility with various Boot and/or Sleuth versions.

[chadlwilson]

Currently it's not initializing the Sleuth part, and I am getting

   SleuthListenerAutoConfiguration:
      Did not match:
         - @ConditionalOnBean (types: brave.Tracer; SearchStrategy: all) did not find any beans of type brave.Tracer (OnBeanCondition)
      Matched:
         - @ConditionalOnClass found required class 'brave.Tracer' (OnClassCondition)
         - @ConditionalOnProperty (decorator.datasource.sleuth.enabled=true) matched (OnPropertyCondition)

With a bit of digging I think perhaps the first thing required here might be some tweaking to the AutoConfigureAfter here.

Seems TraceAutoConfiguration has been moved to BraveAutoConfiguration or TraceConfiguration in Sleuth 3.x - but I don't really have a lot of context or experience with AutoConfiguration at this stage.

If you have some pointers @gavlyukovskiy - an initial attempt for this (without backward compatibility at this stage) is at https://github.com/chadlwilson/spring-boot-data-source-decorator/tree/sleuth-3 - tests are passing, but not yet tested in a real application.

Temporary workaround
Prior to library upgrade, this seems to work (by back-filling the auto-configuration class in your own app). Validated with datasource-proxy and Sleuth 3 only so far, not P6Spy.

package org.springframework.cloud.sleuth.autoconfig;

import org.springframework.boot.autoconfigure.AutoConfigureAfter;
import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;
import org.springframework.cloud.sleuth.autoconfig.brave.BraveAutoConfiguration;

/**
 * Workaround for https://github.com/gavlyukovskiy/spring-boot-data-source-decorator/issues/56
 * and lack of official compatibility with Sleuth 3.
 *
 * <p>This back-fills the deleted class from Spring Cloud Sleuth 2 to support the auto-configuration
 * within the decorator at {@link com.github.gavlyukovskiy.cloud.sleuth.SleuthListenerAutoConfiguration}
 * with versions less than or equal to <pre>1.6.3</pre></p>
 */
@ConditionalOnProperty(name = "decorator.datasource.sleuth.enabled", havingValue = "true", matchIfMissing = true)
@AutoConfigureAfter(BraveAutoConfiguration.class)
public class TraceAutoConfiguration {
}

[gavlyukovskiy]

Hi @chadlwilson, thank you for reporting it, this is very detailed explanation. I looked at your changes and those look really nice. I wonder is it possible to make it compatible with both Sleuth 2.x and Sleuth 3.x?
It seems like brave api didn't change at all, so I think we could change auto-configuration to run after both TraceAutoConfiguration (using string classname instead of .class) and BraveAutoConfiguration while compiling against Sleuth 3.x.

I will have time to look at it on the weekend, do you mind opening PR with what you have done already?

[chadlwilson]

Ahh, thanks for the tip @gavlyukovskiy - didn't realise one could use @AutoConfigureAfter with a class name as string, I'll try that.

Also wasn't sure if Spring Boot will exclude the config if you declare say @AutoConfigureAfter(name={"class1", "class2"} but one of the two classes are not available - will test that. Workaround would perhaps be a separate AutoConfiguration for each Sleuth version with appropriate ConditionalOnClass unless there is a different abstraction for handling that in Spring Boot.

I'd also like to make sure the tests pass against both Sleuth 2 and Sleuth 3 runtime dependencies with the same code which might require some Gradle hijinx.

[gavlyukovskiy]

Also wasn't sure if Spring Boot will exclude the config if you declare say @AutoConfigureAfter(name={"class1", "class2"} but one of the two classes are not available - will test that.

As far as I remember not available classes are just excluded, meaning that auto-configuration will run after all configurations that are available.

I'd also like to make sure the tests pass against both Sleuth 2 and Sleuth 3 runtime dependencies with the same code which might require some Gradle hijinx.

I wouldn't invest much time into that. I don't see a reason to support older versions at cost of messing up with gradle setup - there are older versions of this starter that do support older versions of Sleuth. It's always nice to support as wide range as possible, but I would rather keep tests running only against latest versions Spring Boot, Sleuth, p6spy etc..

[chadlwilson]

Submitted a PR with the fix suggested above - seems to work fine for both Sleuth 2 and 3. Separate branch with an extra commit and attempt at the tests is at https://github.com/chadlwilson/spring-boot-data-source-decorator/tree/sleuth-3-with-backward-compat-and-test-hack but not sure if it's a good idea :-)