Trouble debugging extension

[guw]

Greetings,

I am looking for some guidance for best debugging/working with an extension to vscode-java.

In the package.json file my extension is contributing bundles to JDTLS:

	"contributes": {
		"javaExtensions": [
			"./server/a.b.c.jar",
			"./server/..."
		],
         ....

I have trouble working with this setup at development time. Somehow there seems to be an old cache internally in JDTLS.

I updated a.b.c.jar. I confirmed the updated jar file is in ./server/a.b.c.jar. I launch a new VSCode window with my extension (launch type extensionHost). However, when JDTLS is started I get an exception for something which I clearly fixed in the updated jar file.

I tried "Java: Clean Java Language Server Workspace" command. The action persist. I also think it doesn't clean everything because the client.log file is not cleaned.

I suspect there is an internal Equinox cache somewhere not having the new MANIFEST.MF file (because there are not version on the bundle jars).

Any ideas?

[testforstephen]

The “Clean Workspace” command only clears the project workspace cache, not the OSGI bundle cache.

To avoid issues with the OSGI bundle cache, you have two options:

• Use the OSGI version qualifier to generate a unique version for each build. Since JDTLS bundle installer reuses the cached bundle only if the same bundle version has been installed before. If your bundle version is different, it will uninstall the old one first and then install the new one.
• Delete the OSGI bundle cache directory manually. Depending on your operating system and extension host debugging mode, the cache directory may be located in different places. For Windows, it is usually under the extension installation directory, such as C:\Users\name\extensions\redhat.java-1.21.0\server\config_win. For macOS, it is config_mac. You can delete all folders except config.ini in this directory. If you only see a config.ini file in this directory, then your OSGI bundle cache is in the vscode global storage directory, such as C:\Users\name\AppData\Roaming\Code\User\globalStorage\redhat.java\1.21.0\config_win.

I hope this helps you with your project.

[guw]

Thanks a lot! This is what I was looking for. On my Intel base Mac, the directory is ~/.vscode/extensions/redhat.java-1.2.3-darwin-x64/server/config_mac/.

The version won't change at development time because the bundle version is always "1.2.3.qualifier". For a production build I was stripping of the version number to avoid manipulating package.json. But perhaps I should rethink the process now.

Also, I am wondering if this is a good location of if this should be moved into the workspaceStorage. Could there be different extension in different workspaces?

[rgrunber]

I don't think it's possible to configure different versioned extensions depending on workspace, which is probably why we try to save the state information in global storage. I would also have a look at

vscode-java/src/javaServerStarter.ts

Lines 233 to 262 in 15ddbfe

	function resolveConfiguration(context, configDir) {
	ensureExists(context.globalStoragePath);
	const extensionPath = path.resolve(context.extensionPath, "package.json");
	const packageFile = JSON.parse(fs.readFileSync(extensionPath, 'utf8'));
	let version;
	if (packageFile) {
	version = packageFile.version;
	}
	else {
	version = '0.0.0';
	}
	let configuration = path.resolve(context.globalStoragePath, version);
	ensureExists(configuration);
	configuration = path.resolve(configuration, configDir);
	ensureExists(configuration);
	const configIniName = "config.ini";
	const configIni = path.resolve(configuration, configIniName);
	const ini = path.resolve(__dirname, '../server', configDir, configIniName);
	if (!fs.existsSync(configIni)) {
	fs.copyFileSync(ini, configIni);
	} else {
	const configIniTime = getTimestamp(configIni);
	const iniTime = getTimestamp(ini);
	if (iniTime > configIniTime) {
	deleteDirectory(configuration);
	resolveConfiguration(context, configDir);
	}
	}
	return configuration;
	}

for reference to what's going on. I think we copy the configuration into the global storage fromt he extension installation directory.

[snjeza]

@guv Could you try to remove ./server/config_*/org.eclipse.* ?