Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346565

Summary:

[shared] 64Bit: Eclipse plugins not loading in on x64 with mixed user roles (launching as non-admin)

Product:

[Eclipse Project] Equinox

Reporter:

Allen Zhou <allenwz>

Component:

Assignee:

DJ Houghton <dj.houghton>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

dj.houghton, pascal, pwebster, remy.suen

Version:

3.7

Target Milestone:

Juno M1

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

348013

Attachments:

Description	Flags
patch	none

Description Allen Zhou

2011-05-19 20:37:14 EDT

Build Identifier: 


Installed 64 bit eclipse product as Admin and launched the product as Admin.
Switched to regular user and launched the product and installed other eclipse plugins.
Eclpse plugins installed fine but when re-started the product after installing, eclipse plugins was not loaded.
Note that when installing eclipse plugins as admin, it loads fine.
Also the issue doesn't occur in the 32 bit . It occurs with 64 bit when installing eclipse plugins as non-admin.

Reproducible: Always

Steps to Reproduce:
1.Installed 64 bit eclipse product as Admin and launched the product as Admin.
Switched to regular user and launched the product and installed other eclipse plugins
2.Eclpse plugins installed fine but when re-started the product after installing, eclipse plugins was not loaded.
3.

Comment 1 DJ Houghton

2011-05-24 15:05:18 EDT

This works fine for me with the latest SDK Build. Please include additional information so we can try and reproduce the problem. Thanks.

Comment 2 DJ Houghton

2011-05-31 16:16:56 EDT

I am now able to re-produce the problem with the product-based install. This is similar to the scenario described in bug 322056 comment 7. The bundles are the same in the bundles.info files but the file locations are different (different relative path calculation) so the system believes that the user's bundles.info does not contain all the bundles from the shared location, so it reverts to running the bundles from the shared bundles.info. 

This results in p2 believing that it has something installed (it is in the profile registry, About dialog) but OSGi doesn't think it is installed (it is not in the particular bundles.info we are starting from).

Comment 3 DJ Houghton

2011-06-01 15:55:21 EDT

This problem stems from the fact that the product has the equinox.launcher JARs in 2 locations... in the plugins folder co-located with the exe and also in the shared bundle pool. Because there are 2 copies of the JAR files and each location is considered a repository, the JAR file is available from 2 repositories. So later on we ask for the JAR file and we happen to choose a different one than expected. 

I believe this is related to the cache extensions property and the order of the repositories. In bug 246310 we introduced a sort order in ProfileSynchronizer#synchronizeCacheExtensions so the OSGi install folder would be the first in the list. Later on in the Eclipse touchpoint Util#getAggregatedBundleRepository we iterate over the repositories and return the first location we find it in. 

The problem that we are seeing now is that the OSGi Install Location that we are using for the compare in the array sort, is returned to us by OSGi as an unencoded URL and we are comparing it against repository locations which are URIs. (and therefore characters like spaces are encoded) So in the current code the repository locations look like:
   C:/Program%20Files/Product
but the OSGi install folder looks like:
   C:/Program Files/Product
so it isn't taken into consideration and the repositories are sorted in lexicographical order. Thus when comparing:
   C:/Program%20Files/Product
and:
   C:/Program%20Files%20(x86)/Product
the second one is returned first.

Comment 4 DJ Houghton

2011-06-01 16:30:48 EDT

Created attachment 197171 [details]
patch

Patch which converts the OSGi install folder property to an encoded URI so we can correctly compare it to the repository location URIs.

Comment 5 DJ Houghton

2011-06-07 16:30:24 EDT

Patch released to HEAD. (along with manifest bundle version update)