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
```
Class `FieldBackedProvider` uses ByteBuddy to add a field and its respective getters and setters to store the context object.
Assuming that we have a class `A` that implements runnable and that we wrap with a `FieldBackedProvider`
`Runnable` interfaces, if later on we use a cglib's `Enancher` class on `A` then the our mechanism will kick in again and try
to add the methods again. This causes a `java.lang.ClassFormatError: Duplicate method name "get__datadogContext$java$lang$Runnable" with signature "()Ljava.lang.Object;"`
to be thrown because CGLIB already copied over those methods from the original class `A` to the newly created class.
With this commit we now check that method were not previously defined before adding them, and if they were then we avoid adding them
again.
The reason why it wasn't faiing before is that we only checked on context field existence, not methods and cglib do not copy over fields, it copies only methods. E.g.
```
public class Main {
public static class A {
private String name = "hey";
public String getName() {
return this.name;
}
}
public static void main(String[] args) {
System.out.println("----- 'A' declared fields -----");
A s = new A();
for (Field f : s.getClass().getDeclaredFields()) {
System.out.println("field: " + f.getName());
}
for (Method m : s.getClass().getDeclaredMethods()) {
System.out.println("method: " + m.getName());
}
System.out.println("----- Proxy declared fields -----");
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(A.class);
enhancer.setCallback((FixedValue) () -> null);
A proxy = (A) enhancer.create();
for (Field f : proxy.getClass().getDeclaredFields()) {
System.out.println("field: " + f.getName());
}
for (Method m : proxy.getClass().getDeclaredMethods()) {
System.out.println("method: " + m.getName());
}
}
}
```
Results in:
```
----- 'A' declared fields -----
field: name
method: getName
----- Proxy declared fields -----
field: CGLIB$BOUND
field: CGLIB$FACTORY_DATA
field: CGLIB$THREAD_CALLBACKS
field: CGLIB$STATIC_CALLBACKS
field: CGLIB$CALLBACK_0
field: CGLIB$CALLBACK_FILTER
method: equals
method: toString
method: hashCode
method: clone
method: getName
method: newInstance
method: newInstance
method: newInstance
method: setCallbacks
method: CGLIB$SET_STATIC_CALLBACKS
method: CGLIB$SET_THREAD_CALLBACKS
method: getCallback
method: getCallbacks
method: CGLIB$STATICHOOK1
method: CGLIB$BIND_CALLBACKS
method: setCallback
```
I notice occasionally some of the instrumentation tests fail due to port
conflicts in TestHttpServer, esp when using the `--parallel` option in
gradle. I think the previous method is subject to a race where two
concurrent workers will both get the same port from `randomOpenPort()`.
Previously we were inheriting from the parent and also often setting as a tag.
Apply default span assertion to verify the spanType is being checked properly. (Include error state too.)
Some executors cannot handle tasks that have been wrapped into
`{Runnable,Callable}Wrapper` because they require certain subclass of
`{Callable,Runnable}` in order to work. We have a test that
effectively disables instrumentation for such executors.
This change makes sure that tasks that do not need to be
wrapped (which essentially means anything that is not lambda) still
get traced in such executors. One notable example of affected executor
type is `ScheduledThreadPoolExecutor`.
This will allow better metric collection and identification of trends for individual services/hosts.
This is not enabled by default because it can result in a high cardinality of services.
It turns out that Eclipse's OSGi implementation has two problems:
* It doesn't respect system properties by default
* It has tricky classloader implementation that loads bootstrap
classes from the classloader-has-delegation-to-bootstrap check but
doesn't load bootstrap classes from 'normal' code.
This should address second problem and make Eclipse's OSGi
implementation 'safe' by default.
Tyler Benson
Tyler Benson
Luca Abbati
Ben Keith
Nikolay Martynov
Andrew Kent