-
Notifications
You must be signed in to change notification settings - Fork 16
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
Lightblue plugins have classpath issues in JBossAS #234
Comments
See discussion at http://dev.forum.lightblue.io/Lightblue-Plugin-Design-td425.html |
Possibly also related to lightblue-platform/lightblue-mongo#214 |
I think the problem is that core is assuming the plugins are on the current running classpath, and there's not a good way to safely augment the current classpath. Isolated classloaders are really designed for this class of problem. You probably want to collect URLs to jars to load as plugins, each in their own classloader, and then provide instances of plugins to a LightblueFactory. Each instance's class will be isolated in its own classloader with its own resolution of imports[1]. Either that, or move the plugin resolution inside of core, but I think you'll want to do a similar strategy in any case (load each plugin in its own classloader). [1]: You can write a bottom-up classloader (default is top-down) and then plugins can even include their own copies of common classes that they'll use instead of those already on the classpath of lightblue-rest. |
+1 to moving the functionality into core. The reason it was not initially done that way was to prevent a chicken/egg problem with the datasources.json which is also loaded in lightblue-rest. Likely not an issue for hooks, but a problem for (as an example) the ldap controller. |
We need something like PluginRegistry in core, with plugin jars registered On Tue, May 17, 2016 at 8:23 PM, Dennis Crissman [email protected]
|
The text was updated successfully, but these errors were encountered: