Bugzilla – Full Text Bug Listing
| Summary: | Cannot merge because of disjoint version ranges | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Alex Blewitt <alex.blewitt> | ||||
| Component: | unknown | Assignee: | Glyn Normington <glyn.normington> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | glyn.normington | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 3.0.0.M01 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Alex Blewitt
I think this is working as designed. It seems (a bundle in) the PAR is using import-bundle on two bundles which export the same package. The semantics of import-bundle are that it is equivalent to importing the packages exported by the bundle but *tied* to that bundle, i.e. it's like require-bundle without all the split package and other nasty side effects. So you either need to stop importing one of those bundles or you need to switch to using import-package so that the PAR has some choice about which bundle to get the duplicated package(s) from. No, they're not using Import-Bundle, they're using Import-Package. Let me put a demo PAR together to at least demonstrating it before WONTFIXing it again, huh? Sorry Alex. The diagnostics: Caused by: org.eclipse.virgo.kernel.osgi.framework.ImportMergeException: cannot merge imports of package 'org.osgi.service.jpa' from sources 'Import-Bundle 'demo-0-javax.persistence' version '2.0 .3.v201010191057', Import-Bundle 'demo-0-osgi.enterprise' version '4.2.0.201003190513'' because of disjoint bundle version ranges [4.2.0.201003190513, 4.2.0.201003190513] and [2.0.3.v201010191057 , 2.0.3.v201010191057] then appear to be misleading as they point to the use of Import-Bundle. If you are only using import-package, then there is probably another bug to fix the diagnostics! I'll look forward to the example PAR to reproduce this... Hi Alex. We'd like to look at this bug soon. Please could you supply a PAR to reproduce the problem? I'm afraid we will need to close this as not reproducible unless you can supply a failing case soon. Sorry, it's been busy with being on vacation. I'll try and get to this soon. Still been busy ... No problem. If you can't get round to it, we can close the bug as unreproducible and then you can re-open it if and when you find the time. We'll wait a week or so before doing that though. :-) Created attachment 187661 [details] Test case for bug Running 'maven package' with this file will generate a PAR that exhibits the behaviour described. Here is a result attempting to install it in a fresh Virgo install as a result. Caused by: org.eclipse.virgo.kernel.osgi.framework.ImportMergeException: cannot merge imports of package 'org.osgi.service.jpa' from sources 'Import-Bundle 'bug330643.par-1.0.0.SNAPSHOT-javax.persistence' version '2.0.3.v201010191057', Import-Bundle 'bug330643.par-1.0.0.SNAPSHOT-osgi.enterprise' version '4.2.0.201003190513'' because of disjoint bundle version ranges [4.2.0.201003190513, 4.2.0.201003190513] and [2.0.3.v201010191057, 2.0.3.v201010191057] Note that the relevant lines are: Import-Package: ...org.osgi.services.jpa;uses:="javax.persistence";version="1.0" (OSGi.enterprise) Export-Package: org.osgi.service.jpa;uses:="javax.persistence";version="1.0.0" (javax.persistence) Import-Package: ...org.osgi.service.jpa;version="1.0.0" (javax.persistence) Installing these into a vanilla OSGi runtime (or even in Virgo's kernel region) works. What seems to happen is the version ranges of the bundles are being confused with the versions of hte packages. This is in broad terms working as designed, although admittedly it could be argued that Virgo should be more sympathetic to PARs and scoped plans like this. Let me explain. The synthetic context bundle is generated for a PAR or scoped plan as a means of providing a thread context class loader for the application. The synthetic context bundle imports all the (other) bundles in the PAR or scoped plan using import-bundle. Import-bundle expands to a collection of package imports which are tied to the corresponding imported bundle using the bundle-symbolic-name and bundle-version attributes. The bundle-version attribute specifies an exact version range [bv,bv] where bv is the bundle version of the imported bundle. The intention behind this design is that the packages exported by the bundles in a PAR or scoped plan must form a consistent class space and so split packages are not supported. So if two or more bundles in the PAR or scoped plan export a given package, then deployment should fail, as indeed it does. There is however a bug since Virgo should not be comparing bundle version ranges when the bundle symbolic name attributes are in conflict, since the imported bundles are obviously conflicting regardless of bundle version. This should produce somewhat more meaningful diagnostics. I will investigate fixing this. The reason that this particular PAR could be handled more sympathetically is that the conflicting package exports do not actually conflict because they are also imported by the same bundles. So, after resolution, only one of the bundle will actually export the org.osgi.service.jpa package and the other bundle will import that package from the bundle that exports it. Unfortunately, import-bundle expansion is performed in Virgo prior to resolution, so it is rather tricky for Virgo to get this right. It would have to second guess the resolver and check that both exports are satisfiable by imports in the "other" bundle, or perhaps that at least one of them is. I think this is not a good thing to attempt. It would be better to try to standardise import-bundle so that it could then be processed during resolution in the framework and be sensitive to import/export "dropping". I would recommend meanwhile that PARs and scoped plans are best designed not to include such bundles inside the scope. This is straightforward with plans as an unscoped parent plan can be defined which provides those bundles. With PARs this is trickier as it is necessary to deploy the bundles separately, e.g. using an unscoped plan referring to the bundles as well as the PAR. This will not help people who are using PARs primarily as an archive format. See bug 335689 for a possible way forward. The key here is '...split packages are not supported'. That's basically the red flag in this case. Virgo should document that it doesn't support split packages in the user region because otherwise others might spend hours of frustrated time trying to chase these down. I'm also not sure *why* these aren't supported. It would seem entirely reasonable to make it happen; after all, it works outside a scoped region or even in a plain OSGi runtime. There's no indication in the documentation which says otherwise. The growing concern I have is that even more of the bundles which work at the moment only work when they're exported in the kernel region. Whilst it's true these won't change as much, it does limit the ability to deploy them in a single go. I'm not sure whether bug 335689 is the right way, but it might be a way out. Split packages in the user region *are* supported *except* when they occur inside a single scope (a PAR or scoped plan). Your use case is ok because it only appears, prior to resolution, to have a split package. However, it's quite tricky to second guess the resolver - something we try to avoid doing in Virgo. So I think the best approach with this particular bug is to document the "no split packages in a scope" restriction clearly and improve the diagnostics as described in comment 10. Bug 335689 should certainly give more options for deploying dependencies along with a PAR as a single archive. Restriction documented in commit b04c33763b1b09ff30a0e745000cc3ba35901e19 in the documentation git repo: http://git.eclipse.org/c/virgo/org.eclipse.virgo.documentation.git/commit/programmer-guide?id=b04c33763b1b09ff30a0e745000cc3ba35901e19. The diagnostics improvement now mentioned bundle symbolic names and is a bit more meaningful: <HD0002E> Hot deploy failed for file 'bug330643.par-1.0.0.SNAPSHOT.par'. org.eclipse.virgo.kernel.deployer.core.DeploymentException: Error merging expanded imports for [bundle 'bug330643.par-1.0.0.SNAPSHOT-org.eclipse.persistence.asm' version '2.1.1.v20100817-r8050' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-synthetic.context' version '1.0.0.SNAPSHOT' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-org.eclipse.persistence.jpa.osgi' version '2.1.1.v20100817-r8050' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-org.eclipse.persistence.core' version '2.1.1.v20100817-r8050' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-osgi.enterprise' version '4.2.0.201003190513' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-javax.persistence' version '2.0.3.v201010191057' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-org.eclipse.persistence.jpa' version '2.1.1.v20100817-r8050' in scope 'bug330643.par-1.0.0.SNAPSHOT', bundle 'bug330643.par-1.0.0.SNAPSHOT-org.eclipse.persistence.antlr' version '2.1.1.v20100817-r8050' in scope 'bug330643.par-1.0.0.SNAPSHOT'] at org.eclipse.virgo.kernel.deployer.core.internal.ImportExpandingTransformer.expandImports(ImportExpandingTransformer.java:112) at org.eclipse.virgo.kernel.deployer.core.internal.ImportExpandingTransformer.expandImportsOfBundlesInScopedPlan(ImportExpandingTransformer.java:89) at org.eclipse.virgo.kernel.deployer.core.internal.ImportExpandingTransformer$ImportExpandingTreeVisitor.visit(ImportExpandingTransformer.java:76) at org.eclipse.virgo.util.common.ThreadSafeArrayListTree.visit(ThreadSafeArrayListTree.java:165) at org.eclipse.virgo.kernel.deployer.core.internal.ImportExpandingTransformer.transform(ImportExpandingTransformer.java:58) at org.eclipse.virgo.kernel.install.pipeline.stage.transform.internal.TransformationStage.doProcessTree(TransformationStage.java:55) at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62) at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessTree(CompensatingPipeline.java:72) at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62) at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:277) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:157) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:129) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:196) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:174) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:78) at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:245) at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:166) at org.eclipse.virgo.kernel.deployer.hot.WatchTask.run(WatchTask.java:58) at java.lang.Thread.run(Thread.java:680) Caused by: org.eclipse.virgo.kernel.osgi.framework.ImportMergeException: cannot merge imports of package 'org.osgi.service.jpa' from sources 'Import-Bundle 'bug330643.par-1.0.0.SNAPSHOT-osgi.enterprise' version '4.2.0.201003190513', Import-Bundle 'bug330643.par-1.0.0.SNAPSHOT-javax.persistence' version '2.0.3.v201010191057'' because of conflicting values 'bug330643.par-1.0.0.SNAPSHOT-javax.persistence', 'bug330643.par-1.0.0.SNAPSHOT-osgi.enterprise' of attribute 'bundle-symbolic-name' at org.eclipse.virgo.kernel.userregion.internal.importexpansion.AbstractTrackedPackageImports.mergeAttributes(AbstractTrackedPackageImports.java:144) at org.eclipse.virgo.kernel.userregion.internal.importexpansion.AbstractTrackedPackageImports.mergePackageImport(AbstractTrackedPackageImports.java:119) <etc> With the documentation and diagnostic improvements targetting 3.0.0.M01, closing. |