Summary: | check the value of the default context class loader | ||
---|---|---|---|
Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> |
Component: | Incubator | Assignee: | Thomas Watson <tjwatson> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Jeff McAffer
2003-10-29 09:13:51 EST
The default context class loader in the Framework is the application classloader which includes the startup.jar -> extension classloader -> boot classloader. This is probably not the right choice. Question is what did eclipse used to use as the default context class loader? The boot classloader? The default context class loader is set by the parent thread of eclipse so I would imagine the EclipseStarter would have to set the context classloader to whatever it wants to use as the default class loader for the rest of eclipse. I do not recall classic eclipse doing anything in this area. Perhaps the subject never came up? Seems like the right answer might be the PARENT classloader as defined in RFC70. Seems also that this would have to be set by EclipseStarter. Basiclaly before a thread is forked. What do we want to do here? Set the context classloader to the Bundle ParentClassLoader? From bug 30919 it appears eclipse 2.1 has the context classloader set to the application classloader. Bug 30919 raises the question of whether this is correct or not. It seems to be incorrect since there is no other way to get access to the application classloader from a plugin/bundle in eclipse. If we change this behavior in 3.0 will it be an issue for backwards compatiblity? |