Bugzilla – Full Text Bug Listing
| Summary: | failure to attach fragment w/ BREE to an already resolved host | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | irbull, jwross, lchan, remy.suen, tjwatson, zimmermann |
| Version: | 3.8.0 Juno | ||
| Target Milestone: | Juno M6 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2254 | ||
| Whiteboard: | |||
I could narrow it down to the following commit in org.eclipse.osgi: commit 1adfd1b247f8446241bd426923dacb428c59d539 Bug 368829 - [R5] Represent required execution environment as required capability in osgi.ee namespace Before that everything was fine, with that commit the Import-Package can not be resolved. Reducing severity as I have found the cause and a solution: This method: ResolverBundle.constraintsConflict(BundleDescription, ImportPackageSpecification[], BundleSpecification[], GenericSpecification[]) was returning true for the fragment because newGenericRequires was non-null. Thus removing the BREE from the fragments MANIFEST made its package resolvable again. I'm not 100% sure why this is triggered by the fix from bug 368829. What about BREE in a fragment's manifest: should/must/must not? Is the change in the implementation intended? (In reply to comment #2) > Is the change in the implementation intended? What you describe is not intended. (In reply to comment #0) > You can get corresponding versions of Object Teams from > http://download.eclipse.org/objectteams/updates/ot2.1milestones > Does this still have the BREE specified or has that been updated with your workaround? Going to have to fix this in M6. (In reply to comment #3) > (In reply to comment #2) > > Is the change in the implementation intended? > > What you describe is not intended. > > (In reply to comment #0) > > > You can get corresponding versions of Object Teams from > > http://download.eclipse.org/objectteams/updates/ot2.1milestones > > > > Does this still have the BREE specified or has that been updated with your > workaround? Nevermind, I can reproduce with this URL. This is a real issue that we need to solve. (In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > > > Is the change in the implementation intended? > > > > What you describe is not intended. > > > > (In reply to comment #0) > > > > > You can get corresponding versions of Object Teams from > > > http://download.eclipse.org/objectteams/updates/ot2.1milestones > > > > > > > Does this still have the BREE specified or has that been updated with your > > workaround? > > Nevermind, I can reproduce with this URL. This is a real issue that we need to > solve. I will soon put our M5 into that repo, do you then need a copy for testing? I mean, our M4 will remain unchanged anyway. Regarding my workaround: do you see any issues with omitting the BREE in a fragment / framework extension? Should I keep it that way anyway? Thanks for looking into this. (In reply to comment #6) > > I will soon put our M5 into that repo, do you then need a copy for testing? I > mean, our M4 will remain unchanged anyway. > I have a small testcase to reproduce. So, don't worry about keeping things around. > Regarding my workaround: do you see any issues with omitting the BREE in a > fragment / framework extension? Should I keep it that way anyway? Unfortunately you are going to have to remove the BREE for the time being until we fix this. I will not be able to fix this in M5. The issue is that we now model BREE as actual generic requirements in the osgi.ee namespace. The resolver has a rule no never allow a fragment to attache to an already resolved host if it adds additional requirements. Well, now any fragment with a BREE will add additional requirements to the host it attaches to because its requirements are a payload added to the hosts they attach to. I'm not sure what the best approach is to fix this bug, but it is clear the current behavior is very bad for framework extension bundles. The system bundle is always resolved and therefore we always prevent the attachment of the framework extension if it specifies a BREE! A quick fix is to ignore the requirements in the osgi.ee namespace from fragments when attaching to an already resolved host. I am going to have to open a bug against OSGi to get a clarification on this. It is becoming more clear to me that the osgi.ee namespace should not be treated like other requirements from fragments. The osgi.ee namespace likely should NOT be a payload added to the hosts. Instead it should be resolved as a payload of the fragment itself, similar to the Fragment-Host requirement. I have released a fix and several tests with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a05b273883a39de44a4e65c1eaea59e9d749a95e *** Bug 371874 has been marked as a duplicate of this bug. *** I switched the Object Teams build to use a recent SDK I-Build, reverted my workaround and I can confirm that the bug is fixed for us. Thanks, Tom! |
Trying to install the Object Teams feature into any recent SDK build I get after the restart: org.osgi.framework.BundleException: The bundle "org.eclipse.objectteams.otequinox_2.1.0.201112131519 [383]" could not be resolved. Reason: Missing Constraint: Import-Package: org.eclipse.objectteams.otequinox.hook; version="[2.0.0,3.0.0)" at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:292) at org.eclipse.objectteams.otequinox.internal.hook.TransformerHook.startBundle(TransformerHook.java:708) at org.eclipse.objectteams.otequinox.internal.hook.TransformerHook.startTransformerBundle(TransformerHook.java:694) at org.eclipse.objectteams.otequinox.internal.hook.TransformerHook.watchBundle(TransformerHook.java:648) at org.eclipse.osgi.baseadaptor.BaseAdaptor$3.watchBundle(BaseAdaptor.java:370) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:410) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1177) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) Using all prior version up-to and including Juno M4 this configuration worked flawlessly. The class org.eclipse.objectteams.otequinox.internal.hook.TransformerHook is installed using a hook.configurator. It resides in the very same fragment that exports the package org.eclipse.objectteams.otequinox.hook;version="2.0.0". Seeing the class TransformerHook in the stack I assume that its containing fragment has been resolved correctly, so the package is there. In the stack you then see a call back into the framework: AbstractBundle.start(), where a second (regular) bundle is started programmatically. That bundle has a matching import package for org.eclipse.objectteams.otequinox.hook; version="[2.0.0,3.0.0)". I can see no hint why resolving this package all the sudden fails. The problem can be reproduced by installing Object Teams into any SDK built >= N20120118-2000 (I could no longer find any builds between that and M4). You can get corresponding versions of Object Teams from http://download.eclipse.org/objectteams/updates/ot2.1milestones The corresponding manifests can be found here: http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otequinox.hook/META-INF/MANIFEST.MF?id=builds/201112131519 http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otequinox/META-INF/MANIFEST.MF?id=builds/201112131519