Skip to content
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

Do not expose gocd server class-loader to a plugin #4971

Closed
bdpiparva opened this issue Jul 20, 2018 · 1 comment

Comments

Projects
None yet
3 participants
@bdpiparva
Copy link
Contributor

commented Jul 20, 2018

Issue Type
  • Bug Report
Summary

GoCD server classloader is being exposed to the plugin and it creates an issue in certain scenarios. One such scenario is when plugins dependencies are using current thread classloader to load the class.

public static Class loadClass(String className) throws ClassNotFoundException {
  try {
      ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
      return contextClassLoader.loadClass(className);
  } catch (Exception e) {
      return Class.forName(className);
  }
}

Above code will load the specified class using GoCD server classloader and from GoCD server dependencies which cause plugins to not work.

Basic environment details
  • Go Version: Go Version: 18.7.0 (7118-8494e0df4236380e6b1260f21bea2df13703b64c)
Expected Results

It should load the class from dependencies defined in the plugin, not from the server.

Possible Fix

try {
return plugin.handle(apiRequest);
} catch (UnhandledRequestTypeException e) {
LOGGER.error(e.getMessage());
LOGGER.debug(e.getMessage(), e);
throw new RuntimeException(e);
}

Before submitting a request to plugin set current threads classloader to plugins classloader and revert it back to original classloader at the end.

@bdpiparva bdpiparva added this to the Release: Near term milestone Jul 20, 2018

jyotisingh added a commit to jyotisingh/gocd that referenced this issue Jul 31, 2018

Setting thread context classloader to bundle's classloader before inv…
…oking the plugin - gocd#4971

While osgi handles classloader isolation for the bundle in most cases, thread context classloader was always set to parent's classloader (webapp classloader in this case) causing the plugin to load up classes with Thread.currentThread().getContextClassLoader().loadClass(class-name) from dependencies loaded up by webapp instead of the ones provided by the plugin

akshaydewan added a commit to akshaydewan/gocd that referenced this issue Aug 10, 2018

Setting thread context classloader to bundle's classloader before inv…
…oking the plugin - gocd#4971

While osgi handles classloader isolation for the bundle in most cases, thread context classloader was always set to parent's classloader (webapp classloader in this case) causing the plugin to load up classes with Thread.currentThread().getContextClassLoader().loadClass(class-name) from dependencies loaded up by webapp instead of the ones provided by the plugin

akshaydewan added a commit that referenced this issue Aug 10, 2018

Merge pull request #5011 from akshaydewan/jyotisingh-issue_4971
Setting thread context classloader to bundle's classloader before invoking the plugin - #4971
@maheshp

This comment has been minimized.

Copy link
Member

commented Aug 13, 2018

Fixed as part of #5011

@rajiesh rajiesh closed this Sep 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.