To shift the set-up timing without adding a lot of ugly code (as I did previously), I introduced a lazy dynamic proxy around the repository.
I'm not really happy with this, but I consider it better than the prior approach. There is also probably a more "groovy" way to do this.
As before, this change is itself non-functional. The subsequent test will enable spring-data instrumentation and alter the test.
@Shared runs before the spring-data instrumentation is enabled.
Switching to more explicitly set-up code to change the timing; however, this change doesn't enabled spring-data instrumentation to keep this non-functional.
After seeing the existing elasticsearch 5.3 spring data test, I decided to extend that instead.
However, I do think we need to revisit the best place for tests involving multiple pieces of instrumentation.
Switched to extending JpaRepository rather than CrudRepository, so that multiple spring data integrations can coexist.
Since JpaRepository redefines findAll, this required one update to the test. The other references to CrudRepositopry remain unchanged since JpaRepository extends CrudRepository without redefining those methods.
Rather than using a somewhat ugly solution of implementing both postProcess method signatures.
I'm restricting the integration to newer versions (1.9 - Sept 2014) of spring-data to start.
RepositoryProxyPostProcessor has different method sigs depending on the version of spring-data-commons.
As stop gap implemented both signatures, but probably need to split spring-data support by version.
This revised version targets spring-data RepositoryFactorySupport rather than spring-tx
This is accomplished by injecting a RepositoryProxyPostProcessor during construction that adds a datadog specific MethodIntercptor.
In the end, this functions similarly to the tx support in that it uses a widely scoped MethodInterceptor.
This required some changes to the test as well. The old test set-up the repository before the instrumentation was fully-enabled. Enabling the instrumentation earlier capture extra traces where Spring JPA performs metainfo queries.
This allows trace propagation for CompletableFuture’s asyncPool even if `useCommonPool` is disabled.
Also added some additional futures to `WHITELISTED_FUTURES` and sorted list.
dougqh
Tyler Benson
Laplie Anderson
Douglas Q Hawkins
Laplie Anderson
Nikolay Martynov