Summary: | Problem loading a persistent class in a plugin | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Vladimir <vgusev> |
Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | eclipse |
Version: | 2.1.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Vladimir
2003-07-30 16:06:38 EDT
It seems to me that the solution is very simple. Probably one of the Eclipse methods which are mentioned in the stack trace bellow should initialize the context class loader using: Thread.currentThread().setContextClassLoader(...); Otherwise, no JDO implementation will work from a plugin directly (unless using the workaround mentioned bellow). Setting the context class loader is also done in other environments in which a new thread is assigned to do some user work (with a user private classpath), like in web servers and in application servers. Ilan Kirsh ObjectDB Software http://www.objectdb.com This is a known issue in Eclipse, and unfortunately your workaround is the way to go. For details see: bug 8907, bug 37441 and bug 30588. *** This bug has been marked as a duplicate of 8907 *** Thread.setContextLoader() solution works only if all the persistent capable classes are present in the same plugin. You can do a set contextloader to point the correct plugin classloader while loading each of the classes, however if u have inheritance with super-class in one plugin and subclass in another plugin, chances are that you will never get this work. This is primarily because the persistent-capable subclass uses the persistent-capable superclass to load itself. Solution for this problem has to be provided by jdo vendors, and the workaround wud be to use interface instead of a concrete super-class. Balaji Kandan w: http://www.orangescape.com |