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.
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
Douglas Q Hawkins
Tyler Benson
Laplie Anderson
Laplie Anderson