Ensure that no-isolation workers run with the classloader of the submitting thread #10335
Conversation
…itting thread This fixes a problem where, in a composite build, a worker can get a context classloader set to a classloader from another project, which causes a class mismatch when we attempt to re-hydrate a legacy runnable class in AdapterWorkAction. We now ensure that the context classloader for no-isolation workers get set to the context classloader of the thread that submitted the work.
| def "can use worker api with composite builds using #pluginId"() { | ||
| settingsFile << """ | ||
| includeBuild "plugin" | ||
| includeBuild "build1" |
There was a problem hiding this comment.
could you use a better name for build1? this looks like it's some kind of empty dependency for the root project. Maybe just "dependency"?
There was a problem hiding this comment.
Fair enough - I've changed the project names to "app" and "lib".
| } | ||
|
|
||
| dependencies { | ||
| classpath "org.apache.commons:commons-math:2.2" |
There was a problem hiding this comment.
Is this necessary to trigger the breakage? If so, could you put a comment explaining how this is important?
There was a problem hiding this comment.
It is necessary since classloader caching would cause an identical classpath to be returned for both builds unless there is some difference. However, it's not necessary that it actually be a real dependency. I've changed this to just an un-managed file and eliminated the external dependency.
This fixes a problem where, in a composite build, a worker can get a context
classloader set to a classloader from another project, which causes a class
mismatch when we attempt to re-hydrate a legacy runnable class in AdapterWorkAction.
We now ensure that the context classloader for no-isolation workers get set
to the context classloader of the thread that submitted the work.
Fixes #10317