workaround for jira OSGi modules class loaders #2230
Conversation
| @@ -56,6 +56,11 @@ public boolean matches(final ClassLoader cl) { | |||
| if (v != null) { | |||
| return v; | |||
| } | |||
| // workaround for jira osji modules class loaders: | |||
There was a problem hiding this comment.
Please elaborate on why this is necessary.
There was a problem hiding this comment.
The root issue is that in OSGi the usual parent-child classloader association and visibility rules no longer apply. This can lead to instrumentation class-loading exceptions and log-spam, which as I understand this PR attempts to handle by simply turning off instrumentation for anything loaded by these classloaders.
I'm updating various parts of the tracer to handle class-lookup better when we know OSGi is being used, so this is more of a short-term workaround which we can hopefully drop very soon. If we did want to apply this workaround then I think we should explicitly list the names in canSkipClassLoaderByName rather than introduce another code path here.
There was a problem hiding this comment.
If we did want to apply this workaround then I think we should explicitly list the names in canSkipClassLoaderByName rather than introduce another code path here.
Agreed.
There was a problem hiding this comment.
The problematic atlassian classloaders class name are org.apache.felix.framework.BundleWiringImpl$BundleClassLoader. As far as understand in this workaround we don't want to skip all classloaders of this type. We only want to skip atlassian classloaders. These class loader toString() looks like com.atlassian.analytics.client [<some dynamic digits>] that's why the skip pattern is by prefix, not by explicit classloader name.
I've moved this check to canSkipClassLoaderByName, but now this method name doesn't reflect what is happening inside.
should we skip all classloaders with name org.apache.felix.framework.BundleWiringImpl$BundleClassLoader in this short term workaround?
There was a problem hiding this comment.
OK, so those strings are the Bundle-SymbolicName plus the numeric id of the installed bundle allocated by the runtime. Filtering out classloaders this way is fragile and there are potentially other bundles that suffer from the same issue which won't be skipped (since there's nothing particularly special about these atlassian bundles - they are using the same classloader code as anything deployed on the Felix runtime)
TBH I'd probably prefer to drop the logger level in HelperInjector to temporarily avoid this log-spam
lpriima
force-pushed
the
lp/jiraOSJimodules
branch
from
40a0096
to
c23fc0e
Compare
lpriima
changed the title
|
workaround not needed after: #2321 |
this workaround skips atlassian OSGi (apache felix) by its toString() implementation.