Bugzilla – Full Text Bug Listing
| Summary: | Eclipse-ExtensibleAPI often doesn't work when launching from within Eclipse, fragment Require-Bundle plugins do not resolve | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Chris Lee <eclipse> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aniefer, tjwatson, tmenzel | ||||
| Version: | 3.4.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Chris Lee
Created attachment 176941 [details]
set of projects that attempt (but fail) to repro the bug...
Some more information about how this repros in our environment (still can't repro in attachment though): I've found a simpler workaround to the problem than reimporting projects or changing the JRE - touch the host plugin's manifest file. If (out of the host and fragment's manifest) the fragment's manifest is the last one modified, all the plugins required by the fragment will fail with the "Constraints from the fragment conflict with the host" errors. If the host's manifest is the last one modified, everything works fine. Any ideas why this works and a "Clean/Rebuild" does not work? Any ideas why this problem is occurring at all? I've managed to debug into this issue more (in our debug environment, not in the attached sample), eventually got into some of the bundle loading stuff, and determined that it's related to some sort of bundle state stored in the workspace related to my launch configuration. If I duplicate my launch configuration (while I'm in a "failure" state) and run the new one, it will work fine. Specifically, plugin resolution state is being read from: C:\Workspaces\MyWorkspace\.metadata\.plugins\org.eclipse.pde.core\TestLaunch\org.eclipse.osgi\.state.26 by org.eclipse.osgi.internal.resolver.StateReader.readState / readBundleDescription reads in a 'false' RESOLVED state for my fragment's bundle. If I make no code changes, duplicate the TestLaunch launch configuration, and run using that configuration, it generates 'true' as the RESOLVED state for my fragment's bundle using org.eclipse.osgi.internal.resolver.StateImpl.resolveBundle, and I can launch successfully. Updating platform version to 3.4.2 - Although we're using Eclipse 3.5.2 for our debug environment, it seems that the problem is caused by something in the target environment (3.4.2). This still doesn't seem to affect the sample I attached though... Looking in org.eclipse.osgi.internal.module.ResolverImpl, it seems there's a function 'addDevConstraints' called during resolution, which normally does nothing (since 'developmentMode' is false). If I have my workspace setup to reproduce the problem and set developmentMode=true through the debugger, then the problem doesn't happen - another way to workaround the problem. It seems there's a way to automatically set this to true: org.eclipse.osgi.framework.internal.core.Constants.DEVELOPMENT_MODE.equals(platformProperties[0].get(org.eclipse.osgi.framework.internal.core.Constants.OSGI_RESOLVER_MODE)); How do I do this? Another workaround that should work is to clear the configuration on in your launch configuration. This can be done on the "Configuration" tab. There is a check box under "Configuration Area" for "Clear the configuration area before launching". At first I was confused because I thought your problem was with the fragment resolving in your workspace. And just to confirm, you are not seeing any error markers in the fragment project, correct? It seems like your issue is when you actually launch eclipse then your fragment is no longer allowed to resolve. So this is really an issue with resolving your fragment at runtime when launching from a workspace after you have touched the fragment's manifest. Here is what happens in this case. 1) When launching with a launch configuration from eclipse the runtime checks to see if a bundle manifest has been modified. If so then it forces the bundle to be uninstalled. 2) During launch it is detected that a bundle is missing (that got uninstalled in step 1) and the missing bundle is reinstalled. This is necessary to force the bundle to be reparsed and reloaded with the new content. 3) The framework attempts to resolve the newly installed bundle (fragment in your case). The issue with this fragment case is that it is adding a new requirement to its host. In this case the host is already resolved. We cannot dynamically attach the fragment to the host that is already resolved because the new requirement may corrupt the class space of the resolved host. The only way to attach such a fragment is to force the host to refresh. You can confirm this by adding the -console option to the program args and running the "ss" command. Find your host bundle ID and the call "refresh <host id>". That should force the host to re-resolve and allow the fragment to attach. When launching a built platform that uses p2, the p2 simple configurator will detect such a scenario and perform the refresh on the host bundle for you. (In reply to comment #6) > Another workaround that should work is to clear the configuration on in your > launch configuration. This can be done on the "Configuration" tab. There is a > check box under "Configuration Area" for "Clear the configuration area before > launching". [Chris] This indeed solves the problem as well, and does it in a way I can easily distribute the fix :) > At first I was confused because I thought your problem was with the fragment > resolving in your workspace. And just to confirm, you are not seeing any error > markers in the fragment project, correct? [Chris] Correct - the projects are always building properly. The problem only occurred when the fragment's manifest was modified after the host's manifest. > It seems like your issue is when you actually launch eclipse then your fragment > is no longer allowed to resolve. So this is really an issue with resolving > your fragment at runtime when launching from a workspace after you have touched > the fragment's manifest. Here is what happens in this case. > 1) When launching with a launch configuration from eclipse the runtime checks > to see if a bundle manifest has been modified. If so then it forces the bundle > to be uninstalled. > 2) During launch it is detected that a bundle is missing (that got uninstalled > in step 1) and the missing bundle is reinstalled. This is necessary to force > the bundle to be reparsed and reloaded with the new content. > 3) The framework attempts to resolve the newly installed bundle (fragment in > your case). The issue with this fragment case is that it is adding a new > requirement to its host. In this case the host is already resolved. We cannot > dynamically attach the fragment to the host that is already resolved because > the new requirement may corrupt the class space of the resolved host. The only > way to attach such a fragment is to force the host to refresh. > You can confirm this by adding the -console option to the program args and > running the "ss" command. Find your host bundle ID and the call "refresh <host > id>". That should force the host to re-resolve and allow the fragment to > attach. [Chris] What I've done to try this is put a breakpoint in my Application.run function (so the app stays alive while I run the console). 'ss' shows my host bundle is "Resolved" and my fragment bundle is "Installed". After the refresh, it shows both resolved (and attached with master/fragment bundle id references), and it's fixed. > When launching a built platform that uses p2, the p2 simple configurator will > detect such a scenario and perform the refresh on the host bundle for you. Thanks for the help Thomas - hopefully this is enough information so that this bug can be resolved in the code, eliminating the need for one of these workarounds. For us, updating our launch targets to always "Clear the configuration area before launching" is good enough for now. 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. 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. Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release. |