Description stuart donald 2011-07-17 20:00:23 EDT

Build Identifier: 201107091000

We are developing plugin bundles that do not have the META-INF folder in the directory root (this is common when using a maven style project layout). 

You can tell eclipse about this non standard location by specifying the following key in your org.eclipse.pde.core.prefs settings file:

BUNDLE_ROOT_PATH=${relative path to META-INF folder}

Then when you run the project from within eclipse with a run configuration, eclipse will generate a config.ini, and a dev.properties file, both of which are passed to the osgi runtime - the dev.properties file is mapped to the osgi.dev property.

Here is an example of a generated config.ini. In this setup I have a project/bundle called simple-plugin, and the META-INF folder is located /resources/META-INF

#Configuration File
#Mon Jul 18 11:17:21 NZST 2011
osgi.bundles=reference\:file\:C\:/dev/workspaces/sts2/simple-plugin/resources@start
osgi.bundles.defaultStartLevel=4
osgi.install.area=file\:C\:\\Program Files\\Spring Tool Suite 3.7\\sts-2.7.1.RELEASE
osgi.framework=file\:C\:/Program Files/Spring Tool Suite 3.7/sts-2.7.1.RELEASE/plugins/org.eclipse.osgi_3.7.0.v20110613.jar
osgi.configuration.cascaded=false

And here is the corresponding dev.properties file

#
#Mon Jul 18 11:17:21 NZST 2011
@ignoredot@=true
simple-plugin=../bin

Looking at the config.ini, the resources folder is defined as the bundle root. The dev.properties file is then used to enhance the classpath to find the bin folder using a relative path.

This configuration will work fine with version 3.6 of osgi, but fails with version 3.7.

The culprit appears to be this method in DirBundleFile

	public File getFile(String path, boolean nativeCode) {
		boolean checkInBundle = path != null && path.indexOf("..") >= 0; //$NON-NLS-1$
		File file = new File(basefile, path);
		if (!BundleFile.secureAction.exists(file)) {
			return null;
		}
		// must do an extra check to make sure file is within the bundle (bug 320546)
		if (checkInBundle) {
			try {
				if (!BundleFile.secureAction.getCanonicalPath(file).startsWith(BundleFile.secureAction.getCanonicalPath(basefile)))
					return null;
			} catch (IOException e) {
				return null;
			}
		}
		return file;
	}

The first statement decides that it should check in the bundle because it contains a "..", and the checkInBundle logic then discards this path, as its not in the bundle..

The corresponding method in 3.6 looks like this:

        public File getFile(String path, boolean nativeCode) {
		File filePath = new File(this.basefile, path);
		if (BundleFile.secureAction.exists(filePath)) {
			return filePath;
		}
		return null;
	}

I am not familiar with eclipse to know whether this is an issue with the osgi framework that is parsing the config.ini/dev.properties files, or an issue with the pde or whatever is generating those files. But given that this seems to be a regression in behaviour I have filed against eclipse.osgi.

I have attached a sample project which reproduces the behaviuor.

Reproducible: Always

Steps to Reproduce:
1. Import attached project into eclipse
2. Set up a new OSGi run configuration, that includes the workspace project imported above (simple-plugin - and set start level to start), and the eclipse.osgi 3.7 bundle
3. Launch the run configuration
4. You should see errors like

org.osgi.framework.BundleException: The activator simple_plugin.Activator for bundle simple-plugin is invalid
..
..
Caused by: java.lang.ClassNotFoundException: simple_plugin.Activator
..
..

5. If you were to use the 3.6 OSGi bundle, then "foo" would be printed out on the console.