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.
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.
Unfortunately 404 test was not consistent and non-trivial to adapt. I also couldn’t get the validation tests to work well either. Revisit if we have time to dig deeper into spring.
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.
This is a more generic form of the previous `split-by-domain` and `split-by-instance`.
(Note: evaluation is done when a tag is set, so If multiple tags are configured, the last tag set will take precidence.)
For example, this setting can be used to rename `aws-sdk` spans to be identified with the corresponding `aws.service` tag:
```
-Ddd.trace.split-by-tags=aws.service
```
There are some slight differences with this setting compared with`dd.trace.http.client.split-by-domain` and `dd.trace.db.client.split-by-instance`. `split-by-tags` applies to every span, where `split-by-domain` and `split-by-instance` only apply to http and db client spans respectively.
The core changes are in Config and ServerDecorator.
Moved default tagging from Config::getRuntimeTags to Config::getLocalRootSpanTags. This changes the result of Config::getMergedJmxTags as well.
To preserve language for servers changed ServerDecorator::afterStart.
Other changes are in tests - the most complicated part is in TagsAssert::defaultTags. This now contains a bit too much conditional logic for my liking.
Otherwise it can interfere with the more common Servlet instrumentation (changing the root span name).
Unify attribute/property name for saving span on a request/context.
Also add tests for embedded GlassFish.
(Don’t be surprised when things break with 2.8… They’re religious about removing deprecated methods on minor release versions. If they followed standard convention, they’d likely be on at least 11.x.)
Add client test for 2.4-2.5 http library. 2.6+ won’t work because the underlying frameworks we instrument are shaded.
Also add server tests. We could do a lot more testing since it seems play still supports using Netty as the backing server even though it’s not the default. It’s difficult to do extensive testing though because they have so many breaking changes between versions.
The guava cache used internally wasn’t cleaning (releasing references to) the expired entries properly, resulting in excessive memory overhead.
This PR also increases the size of the cache but reduces the last used expiration window.
I also added some tests to verify the expected behavior of the cache.
This method of using jetty doesn’t seem to work with Servlet’s Async. Native Jetty uses Continuations which we don’t support and should investigate instrumenting.
This change wraps the servlet response object in order to collect the status code. This can be risky if the code is expecting a raw type object. We are extending a standard “HttpServletResponseWrapper” though, so it should be easy to work around.
This change also moves to the standard HttpServerTest for Servlet 2.
Currently missing the authentication tests which need to be added to the parent, but other than that, testing is more thorough.
Discovered that trace propagation for Jetty Async is currently busted so I commented that portion of the test out until we can get it fixed.
Previously the scope was the http client span, which could result in deep nesting. Now it is the parent span.
Before
[——————Parent—————]
[ ^ ———Client—————]
[ ^—Child—]
Now:
[——————Parent—————]
[ ^ —Client—] [ ^—Child—]
Also improve the tests.
The issue we are trying to fix here seems to be a result of two concurrent issues.
Cassandra driver's used by atlas 1.1.0 brings in a old version of netty < 4.0.23.
In version 4.0.25 netty raised exception in `UniqueName` class for duplicate name
```
if (map.putIfAbsent(name, Boolean.TRUE) != null) {
throw new IllegalArgumentException(String.format("'%s' is already in use", name));
}
```
This changed in 4.0.26 where exception was not thrown, instead the duplicate key was just ignored.
```
protected UniqueName(String name) {
this.name = checkNotNull(name, "name");
id = nextId.incrementAndGet();
}
```
Now this alone would not be enough. The only way I was able to reproduce is if two different class loaders tries to load the
same class `AttributeKeys` twice.
I tried to look into Atlas source code (which is huge) and I could not find a clear path of how this would be possible.
Further more, looking at some build scripts that a user experiencing this issue provided,
it looks like they are doing everything correctly and there is nothing they should change.
In conclusion, I believe that even if this is not a very clean approach,
we should be resilient to this use case, when a customer using netty <4.0.25 in an
older version of Apache Atlas (or with some sort of class loader behavior).
Alpha version of Jetty 10 was released and it seems to be compiled for
java versions above 8 so tests fail on java8.
Limit latest dep Jetty tests to Jetty 9 for now.
Alpha version of Jetty 10 was released and it seems to be compiled for
java versions above 8 so tests fail on java8.
Limit latest dep Jetty tests to Jetty 9 for now.
By definition, a Flow generated by a SuperPool does not respect ordering
of requests and responses, and in fact will typically only rarely actually
behave in the fashion that the instrumentation expects. The previous implementation
would start a span for a given request before submitting it as input to the flow,
and close the span with whatever response is next emitted by the flow. This
request will rarely (if ever) be the actual response for the request that
started the span. For more info, see the official docs at
https://doc.akka.io/docs/akka-http/current/client-side/host-level.html#configuring-a-host-connection-pool
Additionally, compiling this instumentation against scala 2.11, and only
scala 2.11 can (and does) cause significant problems at runtime due to the
fact that Scala is explicitly not binary compatible across major versions.
Remove compiled Scala artifacts from the actual instrumentation. Scala
is not binary compatible across major versions, and having
AkkaHttpClientTransformFlow.scala be in the artifact causes problems
when using anything but Scala 2.11.
Having the AkkaHttpClientTransformFlow implementation be in pure java
utilizing the Akka-stream Java DSL ensures that this will work across
any given Scala major version.
For mongo, use description if set, fallback to db name.
Memcache doesn’t have a good “instance name” that would work as service name, so clear it out for now.
We already have a hack to wait for client span to close after the
request because it is closed on separate thread. This patch extends
that hack to handle cases when original request throws an exception.
This ensures that `dd-tracng-ot` gets included into shadow jar.
Before this patch it was included only 'by accident' via some
transitive dependencies of some instrumentations.
This test was not marked as `Specification` and therefor was not run
during builds. Some time ago some code got moved around and this test
got broken - so fixing it.
Move start/stop of servers in smoke tests from gradle code to test
code.
This gives more flexibility in terms of what we can do there.
This also allows us to run servers under test with same JVM as the
test itself - not same jvm as gradle which is currently locked to Java8
dd-jmx-collector
Stack Trace is:
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@10.0.1/Native Method)
- parking to wait for <0x00000007a9ce5448> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@10.0.1/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@10.0.1/AbstractQueuedSynchronizer.java:883)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@10.0.1/AbstractQueuedSynchronizer.java:915)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@10.0.1/AbstractQueuedSynchronizer.java:1238)
at java.util.concurrent.locks.ReentrantLock.lock(java.base@10.0.1/ReentrantLock.java:267)
at org.gradle.internal.remote.internal.hub.MessageHub$ChannelDispatch.dispatch(MessageHub.java:361)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy11.sendOutputEvent(Unknown Source)
at org.gradle.process.internal.worker.child.WorkerLogEventListener.onOutput(WorkerLogEventListener.java:36)
at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@10.0.1/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@10.0.1/Method.java:564)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:230)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:149)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:140)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy10.onOutput(Unknown Source)
at org.gradle.internal.logging.sink.OutputEventTransformer.onOutput(OutputEventTransformer.java:104)
at org.gradle.internal.logging.sink.OutputEventRenderer.onOutput(OutputEventRenderer.java:420)
- locked <0x00000007aa223fc0> (a java.lang.Object)
at org.gradle.internal.logging.sink.OutputEventListenerManager$1.onOutput(OutputEventListenerManager.java:36)
at org.gradle.internal.logging.services.TextStreamOutputEventListener.onTextEvent(TextStreamOutputEventListener.java:57)
at org.gradle.internal.logging.services.TextStreamOutputEventListener.onOutput(TextStreamOutputEventListener.java:41)
at org.gradle.internal.logging.source.PrintStreamLoggingSystem$OutputEventDestination.onOutput(PrintStreamLoggingSystem.java:167)
at org.gradle.internal.logging.source.PrintStreamLoggingSystem$1.text(PrintStreamLoggingSystem.java:44)
at org.gradle.internal.io.LineBufferingOutputStream.flush(LineBufferingOutputStream.java:95)
at org.gradle.internal.io.LineBufferingOutputStream.write(LineBufferingOutputStream.java:80)
at java.io.OutputStream.write(java.base@10.0.1/OutputStream.java:113)
at java.io.PrintStream.write(java.base@10.0.1/PrintStream.java:559)
- locked <0x00000007afd031a0> (a java.io.PrintStream)
at sun.nio.cs.StreamEncoder.writeBytes(java.base@10.0.1/StreamEncoder.java:233)
at sun.nio.cs.StreamEncoder.implFlushBuffer(java.base@10.0.1/StreamEncoder.java:312)
at sun.nio.cs.StreamEncoder.flushBuffer(java.base@10.0.1/StreamEncoder.java:104)
- locked <0x00000007afd03ac0> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flushBuffer(java.base@10.0.1/OutputStreamWriter.java:184)
at java.io.PrintStream.newLine(java.base@10.0.1/PrintStream.java:625)
- locked <0x00000007afd031a0> (a java.io.PrintStream)
at java.io.PrintStream.println(java.base@10.0.1/PrintStream.java:883)
- locked <0x00000007afd031a0> (a java.io.PrintStream)
at org.gradle.internal.io.LinePerThreadBufferingOutputStream.println(LinePerThreadBufferingOutputStream.java:203)
at datadog.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318)
at datadog.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
at datadog.slf4j.impl.SimpleLogger.info(SimpleLogger.java:480)
at org.datadog.jmxfetch.reporter.ConsoleReporter.doSendServiceCheck(ConsoleReporter.java:52)
at org.datadog.jmxfetch.reporter.Reporter.sendServiceCheck(Reporter.java:166)
at org.datadog.jmxfetch.App.sendServiceCheck(App.java:767)
at org.datadog.jmxfetch.App.processCollectionStatus(App.java:1161)
at org.datadog.jmxfetch.App.doIteration(App.java:491)
at org.datadog.jmxfetch.App.start(App.java:424)
at org.datadog.jmxfetch.App.run(App.java:219)
at datadog.trace.agent.jmxfetch.JMXFetch$1.run(JMXFetch.java:99)
at java.lang.Thread.run(java.base@10.0.1/Thread.java:844)
main
Stack Trace is:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.gradle.internal.logging.sink.OutputEventRenderer.onOutput(OutputEventRenderer.java:420)
- waiting to lock <0x00000007aa223fc0> (a java.lang.Object)
at org.gradle.internal.logging.sink.OutputEventListenerManager$1.onOutput(OutputEventListenerManager.java:36)
at org.gradle.internal.logging.services.TextStreamOutputEventListener.onTextEvent(TextStreamOutputEventListener.java:57)
at org.gradle.internal.logging.services.TextStreamOutputEventListener.onOutput(TextStreamOutputEventListener.java:41)
at org.gradle.internal.logging.source.PrintStreamLoggingSystem$OutputEventDestination.onOutput(PrintStreamLoggingSystem.java:167)
at org.gradle.internal.logging.source.PrintStreamLoggingSystem$1.text(PrintStreamLoggingSystem.java:44)
at org.gradle.internal.io.LineBufferingOutputStream.flush(LineBufferingOutputStream.java:95)
at org.gradle.internal.io.LineBufferingOutputStream.write(LineBufferingOutputStream.java:80)
at java.io.OutputStream.write(java.base@10.0.1/OutputStream.java:113)
at java.io.PrintStream.write(java.base@10.0.1/PrintStream.java:559)
- locked <0x00000007a9c6b060> (a java.io.PrintStream)
at sun.nio.cs.StreamEncoder.writeBytes(java.base@10.0.1/StreamEncoder.java:233)
at sun.nio.cs.StreamEncoder.implFlushBuffer(java.base@10.0.1/StreamEncoder.java:312)
at sun.nio.cs.StreamEncoder.flushBuffer(java.base@10.0.1/StreamEncoder.java:104)
- locked <0x00000007a9c6b990> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flushBuffer(java.base@10.0.1/OutputStreamWriter.java:184)
at java.io.PrintStream.newLine(java.base@10.0.1/PrintStream.java:625)
- locked <0x00000007a9c6b060> (a java.io.PrintStream)
at java.io.PrintStream.println(java.base@10.0.1/PrintStream.java:883)
- locked <0x00000007a9c6b060> (a java.io.PrintStream)
at org.gradle.internal.io.LinePerThreadBufferingOutputStream.println(LinePerThreadBufferingOutputStream.java:203)
at datadog.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318)
at datadog.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
at datadog.slf4j.impl.SimpleLogger.formatAndLog(SimpleLogger.java:355)
at datadog.slf4j.impl.SimpleLogger.debug(SimpleLogger.java:446)
at datadog.trace.agent.tooling.context.FieldBackedProvider$1$1$1.visitMethodInsn(FieldBackedProvider.java:202)
at net.bytebuddy.jar.asm.MethodVisitor.visitMethodInsn(MethodVisitor.java:427)
at net.bytebuddy.utility.visitor.ExceptionTableSensitiveMethodVisitor.onVisitMethodInsn(ExceptionTableSensitiveMethodVisitor.java:180)
at net.bytebuddy.utility.visitor.ExceptionTableSensitiveMethodVisitor.visitMethodInsn(ExceptionTableSensitiveMethodVisitor.java:167)
at net.bytebuddy.jar.asm.MethodVisitor.visitMethodInsn(MethodVisitor.java:427)
at net.bytebuddy.utility.visitor.StackAwareMethodVisitor.visitMethodInsn(StackAwareMethodVisitor.java:302)
at net.bytebuddy.jar.asm.MethodVisitor.visitMethodInsn(MethodVisitor.java:427)
at net.bytebuddy.jar.asm.MethodVisitor.visitMethodInsn(MethodVisitor.java:427)
at net.bytebuddy.jar.asm.ClassReader.readCode(ClassReader.java:2214)
at net.bytebuddy.jar.asm.ClassReader.readMethod(ClassReader.java:1283)
at net.bytebuddy.jar.asm.ClassReader.accept(ClassReader.java:688)
at net.bytebuddy.jar.asm.ClassReader.accept(ClassReader.java:400)
at net.bytebuddy.asm.Advice$Dispatcher$Inlining$Resolved$AdviceMethodInliner.apply(Advice.java:7379)
at net.bytebuddy.asm.Advice$AdviceVisitor.onAfterExceptionTable(Advice.java:9427)
at net.bytebuddy.utility.visitor.ExceptionTableSensitiveMethodVisitor.considerEndOfExceptionTable(ExceptionTableSensitiveMethodVisitor.java:49)
at net.bytebuddy.utility.visitor.ExceptionTableSensitiveMethodVisitor.visitLabel(ExceptionTableSensitiveMethodVisitor.java:62)
at net.bytebuddy.jar.asm.Label.accept(Label.java:357)
at net.bytebuddy.jar.asm.ClassReader.readCode(ClassReader.java:1823)
at net.bytebuddy.jar.asm.ClassReader.readMethod(ClassReader.java:1283)
at net.bytebuddy.jar.asm.ClassReader.accept(ClassReader.java:688)
at net.bytebuddy.jar.asm.ClassReader.accept(ClassReader.java:400)
at net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining.create(TypeWriter.java:3393)
at net.bytebuddy.dynamic.scaffold.TypeWriter$Default.make(TypeWriter.java:1930)
at net.bytebuddy.dynamic.scaffold.inline.RedefinitionDynamicTypeBuilder.make(RedefinitionDynamicTypeBuilder.java:217)
at net.bytebuddy.agent.builder.AgentBuilder$Default$Transformation$Simple$Resolution.apply(AgentBuilder.java:10132)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.doTransform(AgentBuilder.java:10551)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.transform(AgentBuilder.java:10514)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.access$1500(AgentBuilder.java:10280)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer$Java9CapableVmDispatcher.run(AgentBuilder.java:10964)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer$Java9CapableVmDispatcher.run(AgentBuilder.java:10902)
at java.security.AccessController.doPrivileged(java.base@10.0.1/Native Method)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer.transform(AgentBuilder.java:10470)
at net.bytebuddy.agent.builder.AgentBuilder$Default$ExecutingTransformer$ByteBuddy$ModuleSupport.transform(Unknown Source)
at sun.instrument.TransformerManager.transform(java.instrument@10.0.1/TransformerManager.java:188)
at sun.instrument.InstrumentationImpl.transform(java.instrument@10.0.1/InstrumentationImpl.java:560)
at java.lang.ClassLoader.defineClass1(java.base@10.0.1/Native Method)
at java.lang.ClassLoader.defineClass(java.base@10.0.1/ClassLoader.java:1009)
at java.security.SecureClassLoader.defineClass(java.base@10.0.1/SecureClassLoader.java:174)
at java.net.URLClassLoader.defineClass(java.base@10.0.1/URLClassLoader.java:545)
at java.net.URLClassLoader.access$100(java.base@10.0.1/URLClassLoader.java:83)
at java.net.URLClassLoader$1.run(java.base@10.0.1/URLClassLoader.java:453)
at java.net.URLClassLoader$1.run(java.base@10.0.1/URLClassLoader.java:447)
at java.security.AccessController.doPrivileged(java.base@10.0.1/Native Method)
at java.net.URLClassLoader.findClass(java.base@10.0.1/URLClassLoader.java:446)
at java.lang.ClassLoader.loadClass(java.base@10.0.1/ClassLoader.java:566)
- locked <0x00000007afb4bc50> (a java.lang.Object)
at java.lang.ClassLoader.loadClass(java.base@10.0.1/ClassLoader.java:499)
at org.gradle.internal.remote.internal.hub.MessageHub.addHandler(MessageHub.java:131)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection.addIncoming(MessageHubBackedObjectConnection.java:98)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.startReceivingTests(TestWorker.java:104)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:68)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:46)
at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:93)
at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:36)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:125)
at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:68)
at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:62)
at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:67)
Expose new options for configuring JMXFetch with standard datadog-agent config files with `jvm_direct: true` set as an instance attribute (this will be ignored by the datadog-agent).
For Example:
* `dd.agent.conf.d=/opt/datadog-agent/etc/conf.d`
* `dd.jmxfetch.configs=activemq.d/conf.yaml,jmx.d/conf.yaml`
will load jmx configs in those two files that have `jvm_direct: true` in their `instance` setup.
Environment variables can also be used: `DD_AGENT_CONF_D` and `DD_JMXFETCH_CONFIGS`
Depends on https://github.com/DataDog/jmxfetch/releases/tag/0.29.0 being released.
Or all executors, bypassing the allow list.
`dd.trace.executor=com.MyCustomExecutor,com.OtherExecutor`
`dd.trace.executors.all=true`
Turns out in many cases, executors that we say we’re skipping, are still being traced because they extend from an already instrumented executor.
Glassfish’s WebappClassLoader caches when a resource or class load fails, so we can’t load as a resource first to see if it is available.
Also add additional logging.
Ensures that span is closed when Observable is unsubscribed from.
Also added retransform error logger since retransforms might be missed if an exception is thrown, leading to odd behavior.
This change is slightly breaking for existing hystrixCommand code since the resource name changes from run->execute and getFallback->fallback. The fallback span is also now a child of the execute span.
Add the following system property or corresponding environment variable:
```
dd.trace.classes.exclude=some.packagename.*,some.classname.MyClass$NestedClass
```
* 'twilio' of github.com:darylrobbins/dd-trace-java:
Updates to handle async calls, which have broken all tests
Missed Gradle file
WIP Twilio SDK Instrumentation
# Conflicts:
# dd-java-agent/instrumentation/twilio/src/main/java/datadog/trace/instrumentation/twilio/TwilioClientDecorator.java
# dd-java-agent/instrumentation/twilio/src/main/java/datadog/trace/instrumentation/twilio/TwilioInstrumentation.java
# dd-java-agent/instrumentation/twilio/src/test/groovy/test/TwilioClientTest.groovy
Merge branch 'twilio' of github.com:darylrobbins/dd-trace-java into twilio
Improved unit testing
* 'twilio' of github.com:darylrobbins/dd-trace-java:
Updates to handle async calls, which have broken all tests
Missed Gradle file
WIP Twilio SDK Instrumentation
# Conflicts:
# dd-java-agent/instrumentation/twilio/src/main/java/datadog/trace/instrumentation/twilio/TwilioClientDecorator.java
# dd-java-agent/instrumentation/twilio/src/main/java/datadog/trace/instrumentation/twilio/TwilioInstrumentation.java
# dd-java-agent/instrumentation/twilio/src/test/groovy/test/TwilioClientTest.groovy
Fix sleep times and choose Java7-friendly test dependencies
Corrected test assertion