Community
Participate
Working Groups
To reproduce the problem, do the following in the IDE on a 32bit Linux box (takes 3 minutes): 1) Create a standard OSGi bundle (as fragment host) 2) Create a standard OSGi fragment bundle and add the following to the manifest: Eclipse-PlatformFilter: (& (osgi.ws=gtk) (osgi.os=linux) (osgi.arch=x86)) 3) Create another standard OSGi fragment bundle and add the following to the manifest: Eclipse-PlatformFilter: (& (osgi.ws=gtk) (osgi.os=linux) (osgi.arch=x86_64)) 4) Create a minimal OSGi run configuration, add the host and the 32bis fragment to it, but not the 64bit fragment. 5) Launch the run configuration. What you will see is that - the OSGi tries to load the 64bit fragment, even though it was not added to the run configuration. - the OSGi does not see the 32bit fragment, even though it was added to the run configuration. Regards, Marton
I'm seeing the same behavior on windows. I have "a.host" and two fragments: "a.frag.32" and "a.frag.64". This message appear during startup: SUBENTRY 2 a.frag.64 2 0 2010-08-16 16:16:10.281 !MESSAGE Platform filter did not match: (& (osgi.os=win32) (osgi.arch=x86_64)) However, if I look at the status of the 2 fragments, the x86 one is resolved and the x86_64 is installed: 1238 initial@reference:file:../../eclipse-dev/dev-3.7/a.frag.64/ INSTALLED a.frag.64_1.0.0.qualifier 1239 initial@reference:file:../../eclipse-dev/dev-3.7/a.frag.32/ RESOLVED a.frag.32_1.0.0.qualifier Tom, does this sound like a framework issue?
(In reply to comment #1) > Tom, does this sound like a framework issue? Does not seem like it, unless you are running on a 64-bit configuration. If that is the case then it looks like the framework allows the wrong fragment to resolve. Otherwise it looks like the framework is allowing the correct 32-bit fragment to resolve while preventing the 64-bit from resolving.
I did the following analysis from the IDE: Bundle loading test: 1) Ubuntu 10.04 32bit, Eclipse RCP 3.6: Run Configuration: + fragment.gtk.linux.x86 - fragment.gtk.linux.x86_64 + fragment.host + org.eclipse.osgi Console output: !ENTRY org.eclipse.osgi 2 0 2010-08-17 10:11:59.298 !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists: !SUBENTRY 1 org.eclipse.osgi 2 0 2010-08-17 10:11:59.298 !MESSAGE Bundle fragment.gtk.linux.x86_64_1.0.0.qualifier [2] was not resolved. !SUBENTRY 2 fragment.gtk.linux.x86_64 2 0 2010-08-17 10:11:59.298 !MESSAGE Platform filter did not match: (& (osgi.ws=gtk) (osgi.os=linux) (osgi.arch=x86_64)) osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.6.0.v20100517 1 ACTIVE fragment.host_1.0.0.qualifier 2 INSTALLED fragment.gtk.linux.x86_64_1.0.0.qualifier 2) Ubuntu 9.04 64bit, Eclipse RCP 3.5: Run Configuration: + fragment.gtk.linux.x86 - fragment.gtk.linux.x86_64 + fragment.host + org.eclipse.osgi Console output: osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.1.R35x_v20090827 1 ACTIVE fragment.host_1.0.0.qualifier Fragments=2 2 RESOLVED fragment.gtk.linux.x86_64_1.0.0.qualifier Master=1 3) Ubuntu 9.04 64bit, Eclipse RCP 3.5: Run Configuration: - fragment.gtk.linux.x86 + fragment.gtk.linux.x86_64 + fragment.host + org.eclipse.osgi Console output: osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.1.R35x_v20090827 1 ACTIVE fragment.host_1.0.0.qualifier Fragments=2 2 RESOLVED fragment.gtk.linux.x86_64_1.0.0.qualifier Master=1 Fragment usage test: fragment host tries to instantiate a class from the fragment with reflection. In the above mentioned test cases: 1) Failed - expected 2) FAILED!!! Despite the fact that the 86bit fragment is resolved. 3) Succeeded - expected
I meant: 2) FAILED!!! Despite the fact that the 64bit fragment is resolved.
I'm seeing a similar issue. I'm running on a Windows Vista 64 bit, Eclipse 3.7.1 32 bit. I have a set of fragments: cdt.core.win32 (selected) cdt.core.win32.x86 (selected) cdt.core.win32.x86_64 (not selected) It only tries to load the x86_64 one.
I had the same problem again but on Linux this time. It looks like this is some kind of caching problem. I edited the manifests of the fragments so that it matched the host plugin version number and other minor cleanups then it worked. Even after I reverted the changes, it still worked. cdt.core.linux (selected) cdt.core.linux.x86 (selected, not loaded) cdt.core.linux.x86_64 (not selected but was attempting to load)
Same problem again on Windows but I think I have a more reliable way to reproduce it and to work around it. 1. Create a run config 2. Select a plug-in that depends on the problematic fragment, like org.eclipse.cdt.ui (I'm using CDT as an example) 3. Click Add Required Plug-ins. It looks like this: cdt.core.win32 (selected) cdt.core.win32.x86 (selected) cdt.core.win32.x86_64 (not selected) Which is fine. But when running: !SUBENTRY 2 org.eclipse.cdt.core.win32.x86_64 2 0 2013-03-15 02:28:21.134 !MESSAGE Platform filter did not match: (&(osgi.os=win32)(osgi.arch=x86_64)) 4. Close the launched Eclipse. 5. Select the plug-in "org.eclipse.equinox.simpleconfigurator" 6. Run again. Correct fragment is loaded. Shouldn't simpleconfigurator be automatically added when clicking Add Required Plug-ins?
Does any one know what simpleconfigurator does and why it fixes the issue?
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. -- The automated Eclipse Genie.
