Comment 1 Martin Frey 2007-09-05 13:37:55 EDT

Created attachment 77746 [details]
jnlp file

Comment 2 Martin Frey 2007-09-05 14:54:23 EDT

I investigated a little and found the following code in the EclipseStarter class:

private static Bundle[] loadBasicBundles() throws IOException {
		long startTime = System.currentTimeMillis();
		String osgiBundles = FrameworkProperties.getProperty(PROP_BUNDLES);
		String osgiExtensions = FrameworkProperties.getProperty(PROP_EXTENSIONS);
		if (osgiExtensions != null && osgiExtensions.length() > 0) {
			osgiBundles = osgiExtensions + ',' + osgiBundles;
			FrameworkProperties.setProperty(PROP_BUNDLES, osgiBundles);
		}
	}
	....
}

I think this is the problem. It simply attaches the extensions name to the bundles instead of the resolved name.

Comment 3 Thomas Watson 2007-09-05 15:12:13 EDT

WebStartMain from org.eclipse.equinox.launcher needs to handle the resolving of the osgi.framework.extensions and placing the content of the extensions onto the classpath of the framework before it launches the framework.

Comment 4 Martin Frey 2007-09-05 17:05:54 EDT

I debugged into the "org.eclipse.equinox.launcher.Main" class and found this the "readFrameworkExtensions" method. I think is responsible for not adding the extension if the url protocol is not "file", it just ignores all other protocols.
If i add the URL generated from the "path" variable to the result arraylist, like in my codesnippet below, the framework is able to run the extension(s). (Which in my case allows to use loadtimeweaving within a webstart rcp application)

Possibly you we could solve this issue with replacing a part of the code with this one? 

if (installLocation.getProtocol().equals("file")) { //$NON-NLS-1$
	extensionResults.add(path);
	extensionURL = new File(path).toURL();
} else if (installLocation.getProtocol().equals("http")) {
	extensionURL = new URL(path);
	result.add(extensionURL);
} else {
	extensionURL = new URL(installLocation.getProtocol(), installLocation.getHost(), installLocation.getPort(), path);
}
-------------------------------------------
private void readFrameworkExtensions(URL base, ArrayList result) throws IOException {
        String[] extensions = getArrayFromList(System.getProperties().getProperty(PROP_EXTENSIONS));
        String parent = new File(base.getFile()).getParent().toString();
        ArrayList extensionResults = new ArrayList(extensions.length);
        for (int i = 0; i < extensions.length; i++) {
            //Search the extension relatively to the osgi plugin 
            String path = searchFor(extensions[i], parent);
            if (path == null) {
                log("Could not find extension: " + extensions[i]); //$NON-NLS-1$
                continue;
            }
            if (debug)
                System.out.println("Loading extension: " + extensions[i]); //$NON-NLS-1$

            URL extensionURL = null;
----------------------> This one here is interesting
            if (installLocation.getProtocol().equals("file")) { //$NON-NLS-1$
                extensionResults.add(path);
                extensionURL = new File(path).toURL();
            } else
            	extensionURL = new URL(installLocation.getProtocol(),   installLocation.getHost(), installLocation.getPort(), path);
---------------------->
            //Load a property file of the extension, merge its content, and in case of dev mode add the bin entries
            Properties extensionProperties = null;
            try {
                extensionProperties = loadProperties(constructURL(extensionURL, ECLIPSE_PROPERTIES));
            } catch (IOException e) {
                if (debug)
                    System.out.println("\t" + ECLIPSE_PROPERTIES + " not found"); //$NON-NLS-1$ //$NON-NLS-2$
            }
            String extensionClassPath = null;
            if (extensionProperties != null)
                extensionClassPath = extensionProperties.getProperty(PROP_CLASSPATH);
            else // this is a "normal" RFC 101 framework extension bundle just put the base path on the classpath
                extensionProperties = new Properties();
            String[] entries = extensionClassPath == null || extensionClassPath.length() == 0 ? new String[] {""} : getArrayFromList(extensionClassPath); //$NON-NLS-1$
            String qualifiedPath;
			if (System.getProperty(PROP_CLASSPATH)==null)
				qualifiedPath = "."; //$NON-NLS-1$
			else
				qualifiedPath = ""; //$NON-NLS-1$
            for (int j = 0; j < entries.length; j++)
                qualifiedPath += ", " + FILE_SCHEME + path + entries[j]; //$NON-NLS-1$
            extensionProperties.put(PROP_CLASSPATH, qualifiedPath);
            mergeProperties(System.getProperties(), extensionProperties);
            if (inDevelopmentMode) 
                addDevEntries(extensionURL, result, extensions[i]);
        }
        extensionPaths = (String[]) extensionResults.toArray(new String[extensionResults.size()]);
    }

Comment 5 Thomas Watson 2007-09-11 09:21:06 EDT

Hi Martin, yes that was the area of the code where I thought we would need to handle this.  Could you provide a patch file with the changes to better illustrate?  Thanks.

Comment 6 Martin Frey 2007-09-13 03:09:05 EDT

Yes i can provide a patchfile for the WebStartMain class. But i think my current fix is more like a workaround. I've debugged through the startup stuff and found a possible problem with the "install.area" property. I'm not sure where this location should point at if the rcp application is launched via webstart. But i saw that the install area looks something like "jnlpcodebase+desktoplocation" which in my case looks like "http://evetrader.mfrey.chC:/Documents and Settings/freym/Desktop". Since this is just the toString from my watch im not sure if its really used like that or if the toString just displays it in this way. In both cases i'd say that the pointer to my desktop is not the right place for the install.area ;) It should probably point to the java cache?

Comment 7 Martin Frey 2007-09-13 03:14:11 EDT

osgi.frameworkClassPath = ., file:file:C:\Documents and Settings\freym\Application Data\Sun\Java\Deployment\cache\6.0\7\b3b8187-19ab6cbf
osgi.install.area = http://evetrader.mfrey.ch/C:/Documents and Settings/freym/Desktop
osgi.instance.area = file:/C:/Documents and Settings/freym/Application Data/evetrader/


These properties could be interessting.

Comment 8 Josh Arnold 2007-09-24 14:24:30 EDT

(In reply to comment #6)
> But i saw that the install area looks something like
> "jnlpcodebase+desktoplocation" which in my case looks like
> "http://evetrader.mfrey.chC:/Documents and Settings/freym/Desktop". Since this
> is just the toString from my watch im not sure if its really used like that or
> if the toString just displays it in this way. 

I think that's a real problem.  It looks like it happens in org.eclipse.core.runtime.adaptor.EclipseStarter.initializeProperties().   That method tries to munge the osgi.install.area property based on the CodeSource URL of the EclipseStarter class.  Unfortunately, in Java 6, that URL became the URL the jar was downloaded from.

This problem seems to prevent Equinox from loading previously installed bundles.  The net effect is that all the bundles get uninstalled and reinstalled each time you launch the application.  

This actually causes a problem in one of my bundles because that uses  BundleContext.getDataFile() to get a persistent storage location.  Since the bundle gets reinstalled each time you launch, that directory also changes each time you launch.

Comment 9 Martin Frey 2007-09-25 04:52:26 EDT

Here's the patchfile from the Main class. However it's working i think it's more of a workaround. I've attached also the working plugin of the launcher.

greetings
Martin

Comment 10 Martin Frey 2007-09-25 04:53:19 EDT

Created attachment 79111 [details]
Patchfile for Main.java

Comment 11 Martin Frey 2007-09-25 04:54:37 EDT

Created attachment 79112 [details]
Working plugin for JNLP

Comment 12 Tom Huybrechts 2007-11-11 16:47:12 EST

I tried setting osgi.install.area explicitly in my JNLP file.
Then everything goes well except for one detail: the path returned from searchFor(extensions[i], parent) is not relative to the osgi plugin as stated in the comments. Instead it is an absolute file URL (starting with "file:"), pointing to the location of the extension bundle in the webstart cache. 

The path variable is added to qualifiedPath later, and there "file:" is prepended to the URL again, so now it has "file:file:...". If you avoid this by dropping the "file:" in the beginning, all goes well.

Comment 13 Eclipse Webmaster 2019-09-06 16:05:32 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

Comment 14 Eclipse Genie 2021-09-07 15:39:12 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.