Community
Participate
Working Groups
WTP 3.0 build I20080326051939 In the new WTP that uses Equinox p2, Web service scenarios are broken at places where we need to copy files from the plugin to the workspace. An error such as the one below is issued: IWAB0506E Error when copying Axis jar files to web project java.io.FileNotFoundException: D:\WTP\3.0\20080326051939\eclipse\ce:file:dropins\eclipse\plugins\javax.wsdl_1.5.1.v200803061910.jar (The filename, directory name, or volume label syntax is incorrect) Notice that the path segment "ce:file:dropins" is wrong and should be just "dropins".
A quick look through the Web service code shows that it just getting the plugin install directory using platform bundle APIs, i.e.: <snip> Bundle bundle = Platform.getBundle( bundleId ); URL installURL = bundle.getEntry("/"); URL fileURL = new URL(installURL, path ); return fileURL; </snip>
This needs to be fixed in this week's I-build for WTP 3.0 M6.
where is that "path" segment coming from?
A correction about my previous comment, I was looking at the wrong method. This is actually what we are using: static public IPath getJarredPluginPath(String bundleId) { IPath result = null; Bundle bundle = Platform.getBundle(bundleId); if (bundle != null) { Path runtimeLibFullPath = null; String jarPluginLocation = bundle.getLocation().substring(7); Path jarPluginPath = new Path(jarPluginLocation); // handle case where jars are installed outside of eclipse installation if (jarPluginPath.isAbsolute()) runtimeLibFullPath = jarPluginPath; // handle normal case where all plugins under eclipse install else { String installPath = Platform.getInstallLocation().getURL().getPath(); runtimeLibFullPath = new Path(installPath + "/" + jarPluginLocation); //$NON-NLS-1$ } result = runtimeLibFullPath; } return result; } The substring(7) looks a bit suspicious to me, but at the moment I'm having trouble getting self-hosting working with a P2'd WTP build so I can't trace thru the code to see what's happening there.
(In reply to comment #4) > > The substring(7) looks a bit suspicious to me, but at the moment I'm having > trouble getting self-hosting working with a P2'd WTP build so I can't trace > thru the code to see what's happening there. > I'm sure that's it. Looks like what you want is some way to go from a Bundle's URL location to an IPath? I'm not sure that's (always) possible ... any chance you can not use an IPath?
Yes, that code looks like it's making some bad assumptions. This also looks wrong: String installPath = Platform.getInstallLocation().getURL().getPath(); runtimeLibFullPath = new Path(installPath + "/" + jarPluginLocation); //$NON-NLS-1$ I suspect there are other scenarios where this would have failed in the past (using extension locations for example). You are likely getting a reference: URL back from Bundle.getLocation(), hence the "ce:file:" path. Tom, can you recommend the right thing to do here? FileLocator#resolve I assume.
Created attachment 93679 [details] patch Actually, we ultimately want to get a File object for the plugin jar file, and I found that we can do that much more easily using FileLocator.getBundleFile() API call. This patch bypasses using BundleUtils.getJarredPluginPath() completely and I tested that it works in both pre/post P2 environments. I also propose to deprecate the getJarredPluginPath() method.
Yes exactly, in P2 Bundle.getLocation() was returning "reference:file:dropins\eclipse\plugins\xyz.jar" Is it safe to assume FileLocator.getBundleFile() will work for extension location case?
(In reply to comment #7) > Created an attachment (id=93679) [details] > patch > > Actually, we ultimately want to get a File object for the plugin jar file, and > I found that we can do that much more easily using FileLocator.getBundleFile() > API call. Yes this is the recommended way to get the path to the bundle content. Note that this may be a jar or a directory depending on how the bundle was installed. (In reply to comment #8) > Yes exactly, in P2 Bundle.getLocation() was returning > "reference:file:dropins\eclipse\plugins\xyz.jar" > > Is it safe to assume FileLocator.getBundleFile() will work for extension > location case? > Yes this should work no matter where the bundle is installed on disk.
Created attachment 93694 [details] updated patch After discussing with Kathy, we will fix the getJarredPluginPath() method also, since there are some other code using it. Thanks for everyone's input!
Patch committed and released to HEAD as v200803262125. Thanks Andrew for the speedy resolution!
Created attachment 93706 [details] patched org.eclipse.jst.ws.axis.consumption.ui plugin
Created attachment 93708 [details] patched org.eclipse.wst.ws plugin
For reference, I've opened bugs on other places where we've copied this method ... I think we all know who started it :) [and it wasn't Kathy or her team :) ] bug 224382 bug 224384
mass change to add 'contributed' keyword based on bugzilla query, please correct if that's not accurate (by marking patches as obsolete and removing the 'contributed' keyword.
This problem has been long fixed and released. Verified and closing.
