OSGi classloading workaround + refactor servlet contants#2418
OSGi classloading workaround + refactor servlet contants#2418SylvainJuge merged 13 commits intoelastic:mainfrom
Conversation
apm-agent-core/src/test/java/co/elastic/apm/agent/logging/LoggingConfigurationTest.java
Outdated
Show resolved
Hide resolved
…ingConfigurationTest.java Co-authored-by: eyalkoren <41850454+eyalkoren@users.noreply.github.com>
| // OSGi bundles might only include 'jakarta.servlet' and not 'jakarta.servlet.http' (same for `java.servlet`), hence | ||
| // this allows to disable instrumentation as it is required for our instrumentation code. | ||
| .and(CustomElementMatchers.classLoaderCanLoadClass(osgiClassloaderFilterClass)); |
There was a problem hiding this comment.
[for reviewer] this is what provides the work-around for OSGi by requiring ability to load a class in javax.servlet.http.* or jakarta.servlet.http.* packages.
There was a problem hiding this comment.
This workaround assumes that at least one class on the execution stack is loaded by a class loader that knows both javax.servlet and javax.servlet.http. So far it seems to be a valid concept, but let's keep that in mind as a possible source for future reports on missing endpoints.
|
I have also added a simple work-around for Apache Sling throwing |
| ClassLoader servletContextClassLoader = adapter.getClassLoader(servletContext); | ||
| ClassLoader servletContextClassLoader = null; | ||
|
|
||
| if (!servletContext.getClass().getName().startsWith("org.apache.sling")) { |
There was a problem hiding this comment.
[for reviewer] we explicitly exclude Apache sling implementation here (and not in the adapter) as it allows to also cover the case where it's migrated to jakarta.servlet, The downside of this is that the service name detection might not work as expected, but with Sling it creates 7+ distinct services for a simple demo app, thus we can expect users to set their service_name explicitly.
|
/test |
eyalkoren
left a comment
There was a problem hiding this comment.
I really like the refactoring! 👏
A negative added-removed balance in PR lines is a great indication for something good 😄
The main comment is about losing class loader references within class loaders. I prefer we only do that on special cases. Class loaders refs within class loaders should represent the delegation hierarchy as much as possible in my opinion.
| @Override | ||
| public String toString() { | ||
| return "DiscriminatingMultiParentClassLoader{" + | ||
| "agentClassLoader = " + parents.get(0) + " discriminator = "+ discriminators.get(0) + | ||
| ", targetClassLoader =" + parents.get(1) + " discriminator = " + discriminators.get(1) + | ||
| '}'; | ||
| } |
...gent-core/src/main/java/co/elastic/apm/agent/bci/classloading/ExternalPluginClassLoader.java
Outdated
Show resolved
Hide resolved
| public String toString() { | ||
| return "ExternalPluginClassLoader{" + | ||
| "pluginJar=" + pluginJar + | ||
| ", agentClassLoader=" + agentClassLoader + |
There was a problem hiding this comment.
Could that be something other than the single agent CL?
apm-agent-core/src/main/java/co/elastic/apm/agent/bci/classloading/IndyPluginClassLoader.java
Outdated
Show resolved
Hide resolved
| // OSGi bundles might only include 'jakarta.servlet' and not 'jakarta.servlet.http' (same for `java.servlet`), hence | ||
| // this allows to disable instrumentation as it is required for our instrumentation code. | ||
| .and(CustomElementMatchers.classLoaderCanLoadClass(osgiClassloaderFilterClass)); |
There was a problem hiding this comment.
This workaround assumes that at least one class on the execution stack is loaded by a class loader that knows both javax.servlet and javax.servlet.http. So far it seems to be a valid concept, but let's keep that in mind as a possible source for future reports on missing endpoints.
apm-agent-plugins/apm-servlet-plugin/src/main/java/co/elastic/apm/agent/servlet/Constants.java
Outdated
Show resolved
Hide resolved
| String servletResponseClassName() { | ||
| return "jakarta.servlet.ServletResponse"; | ||
| public Constants.ServletImpl getImplConstants() { | ||
| return Constants.ServletImpl.JAKARTA; |
Add debug logging to help understanding what could cause #2104UPDATE: re-purposing this PR
ServletAPI.SecurityExceptionthrown by Apache SlingFixes #2104