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
```
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
```
Currently helpers will not be injected if instrumentation doesn't
apply. Unfortunately it is possible for some classes to have context
fields added even if instrumentation is not allied (i.g. instrumented
classes are not used). Fix this by always injecting all helpers if we
inject context fields.
This can cause problems if muzzle prevents an integration from loading because the class for the new field being added may not be injected. This results in an error:
```
Caused by: java.lang.NoClassDefFoundError: datadog/trace/bootstrap/instrumentation/context/FieldBackedProvider$ContextAccessor$org$hibernate$Session$datadog$trace$bootstrap$instrumentation$hibernate$SessionState
```
Serialize payloads as they arrive, send to agent when size exceeds 5MB.
If a flood of traces fills up the RingBuffer, we still count the traces that are discarded for stats reporting.
Do we want to allow configuration of the RingBuffer size?
I considered excluding Interfaces too, but that would break people that added `@Trace` to their default methods.
Just a hunch, but I don’t think we want to instrument classes marked as synthetic, for example proxies. We may want to extend this to our method matchers (and maybe exclude native methods too).
We might want to instrument enums/annotations, but that seems unlikely.
Not doing this seems to cause issues with Clojure protocols.
An application instrumented with the dd-java-agent that will
otherwise run fine will fail with ClassNotFoundException for
classes pertaining to Clojure protocols.
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.
The problem there is that it references JVM shutdown hook that keeps
reference to cleanup executor which potentially can keep references to
all sort of things - and this doesn't get cleaned up untill JVM
shutdown.
Solution is to remove shutdown hook when supplier is being GCed.
Tyler Benson
Rafael Winterhalter
Tyler Benson
Luca Abbati
Nikolay Martynov
Will Gittoes
Daniel Solano Gómez
Andrew Kent
Gary
Andrew Kent