I've put a patch into tha Patch Tracker. Has it been reviewed yet? Will it be introduced in some future release?
In general the policy is that random tweaks for a one-off application cannot be committed to in the core, but changes needed to support a class of applications or uses may be. I saw your patches but you didn't offer an explanation on why they are needed. Why isn't the current classpath augmentation sufficient?
Sorry I forgot to explain it thoroughly.
The root problem is that there can be a custom ClassLoader, which loads Multivalent. In jEdit there is one. Besides that, there can be a custom protocol, and in jEdit there is one. So jEdit's class loader loads classes and resources from
That means the original findJars() is not sufficient for loading the jars along with Multivalent.jar. To make the minimal change, I added a new getInstance, that can get an array of jars to load classes and resources from.
I just handle the exception, because after embedding Multivalent, it was thrown. I think this is because something is changed when Multivalent is loaded via another class loader.
My current development version has code that does not attempt a search for other JARs on non-standard protocols.
But there shouldn't be a need to explicitly set additional JARs. The following excerpt from your patch:
- cl_ = new URLClassLoader(findJARs(), Multivalent.class.getClassLoader());
+ if (myJars==null) myJars=findJARs();
+ cl_ = new URLClassLoader(myJars, Multivalent.class.getClassLoader());
shows that it already uses the URLClassLoader constructor that also uses the prevailing classpath upon entry, so you should be able to place Multivalent.jar and any others in that classpath. Right?
Log in to post a comment.