Bug #18
closed
ClassLoader for generated bytecode
100%
Description
SourceForge user: mhkay
When Saxon-EE generates bytecode, it loads the generated classes using a custom ClassLoader whose parent ClassLoader is obtained using getClass().getClassLoader(). In some circumstances this parent ClassLoader can subsequently be invoked for loading resources such as extension functions referenced by the generated bytecode. In an environment with specialized class loading requirements, this may be inadequate, and it may be preferable to use the context class loader for the thread instead. A patch is being raised whose effect is to choose which ever of the following first produces a result:
(a) the user-defined ClassLoader registered with configuration.getDynamicLoader().setClassLoader()
(b) the result of Thread.currentThread().getContextClassLoader()
(c) the result of getClass().getClassLoader()
This is consistent with the strategy Saxon generally uses for dynamic loading of classes.
Updated by Michael Kay about 12 years ago
- Assignee set to O'Neil Delpratt
Although this patch seems to have worked well on the Java platform, it appears to have caused regression on .NET, where class loading is now failing in cases where the application uses the Saxon API to compile queries and stylesheets (it works fine when Saxon is run from the command line).
Updated by O'Neil Delpratt about 12 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
The bug has now been fixed. We now rely on the sub-classes of the the platform class to create the classLoader object. Therefore the logic required for a Java and .NET platform is in place, respectively.
Updated by Michael Kay almost 12 years ago
- Status changed from Resolved to Closed
- Fixed in version set to 9.4.0.3
Please register to edit this issue
.