Community
Participate
Working Groups
I'm attempting to integrate third-party libs to my plugin and the libs are using JAAS. Got a lot of problems with the library: - if I put JAAS to lib folder of my plugin and register it in <runtime> declaration, I get java.lang.SecurityException: unable to instantiate LoginConfiguration at javax.security.auth.login.Configuration.getConfiguration (Configuration.java:212) at javax.security.auth.login.LoginContext$1.run(LoginContext.java:166) at java.security.AccessController.doPrivileged(Native Method) ... Which according to the sources of Configuration is internal "ClassNotFoundException" for class, which is in the same jaas.jar ("com.sun.security.auth.login.ConfigFile"). - if I put jaas.jar to my default jre (jre/lib/ext), the jar is locked by Eclipse, but I get "ClassNotFound" exception for the first class access attempt. Question: is there any way to define how classpath will be for a particular plugin? If not, may be there is a way to define additional classpath entries for all plugins? I tried to run eclipse with -vmargs -cp %myclasspath% options - no effect in run-time workbench, no classes found from this classpath. I tried run-time workbench with -dev %myclasspath% - getting plenty of ClassNotFoundExceptions from workspace plugins (seems, like "-dev bin" is not a just example, but only working combination, since "-dev bin,something" doesn't allow access to 'something') The third-party libraries, I work are extensively use classpath (e.g. they load/write resources from classpath), the only way I found how to pass directory in classpath (i.e. location for files, where they can be overwritten), is to put the files to jre/lib/classes, which seem to appear in base classpath for all plugins. Any other ways? I think there something wrong in classloader (or in combination of classloaders) of Eclipse, since I can run "main" method in my plugin (i.e. execute it as standalone java application) without any problems, but this must be a plugin functionality. Sorry if I incorrectly set severity as "blocker", but I'm trying to resolve the issue for several days now, community is not responsive, so only authors can help. Thank you in advance!
There is no way to change the classpath of a plugin at runtime. Could you please give more details on what you are trying to achieve, especially what you meant by reading and writing. Does this problem only occurs with JAAS, or does it also occurs with other libraries? Which VM and SDK are you using? Please move this bug to Platform/Core and also create a PR in PDE-UI for the bug related to the -dev param problem. Thank you.
The libraries, I'm using, are parsing some XML files, which must be in classpath. Also the files are serialized back sometimes. To prevent "ResourceNotFound" exception, I put the files to a jar file, which declared in <library> of plugin and the reading phase passed through. However some time later I get "IOException" on attempt to write xxxjar!xml.xml. If I put the files to jre/classes - this stuff works well. So far the problem occurred only with JAAS. Note: I had quite strange experience with it - the libraries, I use, were delivered with JAAS1.0 and I did a lot of things to work the problem out (Unable to instantiate LoginConfiguration) without any success. Finally I went to SUN site and downloaded JAAS1.0_01. After replacement of the jar (I didn't restart Eclipse), my application worked correctly. Next day (restart of computer) situation repeated - again the same exception. Right at the moment I use the following solution: ClassLoader loader = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); <call to the library> Thread.currentThread().setContextClassLoader(loader); This works well, no exceptions. However I can't debug application at all. On first break-point occurrence (stack traces in debugger show all thread properly, including suspended one), there is GPF in JVM.DLL, and run-time workbench closes at once. I don't think that the classloader trick above has something to do, because I had this GPF even before introduction of the code and thought it's because of classpath problems... I'm running JDK1.3.1 (the libraries are fixed to 1.3, do not allow 1.4), Eclipse 2.1 (I've tried latest 2.1.1 with the same result). Switching to Platform/Core
Reassigning...
This looks like a WONTFIX. We know the "ext" directory is not available to the Eclipse classloaders. See the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=30919 Also true that the context classloader is not set to something meaningful in Eclipse. However, each plugin has its own classloader, and each thread has its own classloader. Since there is no consistent mapping between threads and plugins, we can't set the context classloader to anything useful. Your workaround to set the context loader before/after the library call is the standard solution that people have been using. See the following discussions on the Eclipse wiki: http://eclipsewiki.swiki.net/114#context http://eclipsewiki.swiki.net/114#eclipseClassloading http://eclipsewiki.swiki.net/114#augmentedClasspath
