Forum Discussion
paulhanke
15 years agoNew Contributor
I once wrote a work-around for sharing dynamically-generated classes across OSGi module boundaries ... the work-around may have been Felix-specific, but as far as I can tell loadUI uses Felix ... in a nutshell, the trick is to switch the current thread's class loader for as long as you need to create objects from another class loader ... in your case, it might go something like this (assuming that it is a channel that is being passed from A to B):
ClassLoader threadLoader = Thread.currentThread().getContextClassLoader()
Thread.currentThread().setContextClassLoader(channel.getClass().getClassLoader())
// create/derive needed instances here
Thread.currentThread().setContextClassLoader(threadLoader)
Potential issues with this approach:
- I've never tried it in Groovy
- it may fail due to loadUI security restrictions
- if your listener needs access to both class loaders you may need to store those loaders as fields and switch back and forth as needed
ClassLoader threadLoader = Thread.currentThread().getContextClassLoader()
Thread.currentThread().setContextClassLoader(channel.getClass().getClassLoader())
// create/derive needed instances here
Thread.currentThread().setContextClassLoader(threadLoader)
Potential issues with this approach:
- I've never tried it in Groovy
- it may fail due to loadUI security restrictions
- if your listener needs access to both class loaders you may need to store those loaders as fields and switch back and forth as needed