-
-
Notifications
You must be signed in to change notification settings - Fork 810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Cannot resolve type description" when class is not present #780
Comments
It's less a bug than it's a feature. "Optional types" is something several developers assume for the JVM to work due to it's implicit type resolution but for legally transforming a type, all signature type information needs to be available during instrumentation. Byte Buddy requires all type information for a transformed type to be available but for Class.forName("ch.qos.logback.classic.Logger").getDeclaredMethods() Introspection only works if the introspected types are available. The good news is that this does not break anything but only aborts the instrumentation of the incomplete type. |
Well, it does seem to break Would it be possible to add some graceful handling of such cases? |
It should not and I cannot reproduce this behavior from the example either. I assume that you see this single log statement but otherwise, everything works as expected. If a retransformation fails (due to an unhandled error typically), you can split batches by using for example: You can also suppress installation errors by For ignoring methods with incomplete signatures, you could add a |
Sorry, I had a side effect that made me think that the whole instrumentation fails, so it is indeed only about logging. However, adding The error seems to happen when the class is being defined (initial classloading) and reported in byte-buddy/byte-buddy-dep/src/main/java/net/bytebuddy/agent/builder/AgentBuilder.java Line 10466 in dcbdc13
which goes directly to |
That was what I expected. The installation only fails when errors are not catched by Byte Buddy and illegal byte code is issued. This should never happen but can occasionally with very rare byte code combinations, typically when other Java agents are involved. |
I assume the question is answered, therefore I am closing this. |
Hi!
We received a bug report in BlockHound ( reactor/BlockHound#71 ) that looks more like a bug in ByteBuddy.
I was able to reproduce it with the following setup:
It fails with this exception:
java.lang.IllegalStateException: Cannot resolve type description for org.slf4j.event.LoggingEvent
The text was updated successfully, but these errors were encountered: