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.
The SpringDataDecorator is really for Spring transactions including non-DB related transactions.
The SpringDataDecorator never really implemented DB or ORM support anyway, since most of the methods just returned null.
Changing the decorator to just extend ClientDecorator instead. Also rename to reflect its true purpose.
Switching muzzle to target spring-tx rather than spring-data (which is logical given the instrumentation point)
Also added extraDependency on aopalliance
This restricts the support the Spring 2.5 when spring-tx & spring-aop using aopalliance were introduced.
After experimenting with RepositorySupport$QueryExecutorMethodInterceptor switched to TransactionInterceptor.
QueryExecutorMethodInterceptor was too narrowly scoped and didn't capture the UPDATE or DELETE statement. TransactionInterceptor captures everything, but is still a bit more broadly applicable than I'd like.
Added some explanatory comments for each span -- might turn these into assertions later
Primary aim was to understand the differences from the signalfx fork. They seem to stem deviations in the underlying JDBC integration.
dougqh
Ryan Fitzpatrick