-
Notifications
You must be signed in to change notification settings - Fork 326
lazy-load jdbc helper #1409
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
lazy-load jdbc helper #1409
Conversation
...ent-plugins/apm-jdbc-plugin/src/main/java/co/elastic/apm/agent/jdbc/JdbcInstrumentation.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| protected synchronized static JdbcHelper getJdbcHelper() { | ||
| // lazily initialize helper to prevent trying to load classes in java.sql package with the bootstrap classloader |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that an indication that we should more strictly separate advices from element matches?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say yes, separation would be better. In the same category, there is getAdviceClass() method that returns the advice class loaded from agent/bootstrap classloader when in practice we only use class name and then load it in child-first plugin classloader. We already discussed that a bit with @eyalkoren last week.
What does this PR do?
JDBC instrumentation fails on some environments when active.
This appears to be a side-effect of migration to new plugin architecture introduced in version 1.18.0.
We haven't been able to reproduce this directly, but changes have been confirmed to work where it used to happen.
Checklist