Bugzilla – Full Text Bug Listing
| Summary: | [region] no check for duplicate BSN/version is done on Region.installBundle | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Thomas Watson <tjwatson> | ||||
| Component: | Components | Assignee: | equinox.components-inbox <equinox.components-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | glyn.normington | ||||
| Version: | 3.7 | Keywords: | Documentation | ||||
| Target Milestone: | 3.7 RC3 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Thomas Watson
Created attachment 196344 [details]
work in progress
This is work in progress if we decide such a change is a good idea. Still need to write tests. But tests get complicated because of the need to set the property org.osgi.framework.bsnversion=multiple. Will likely have to fire up another framework instance configured properly to test.
I agree that it would be good to establish this invariant. Knowing that the combination of region id, bundle symbolic name, and bundle version is sufficient, within a given framework, to uniquely identify a bundle is a very useful property. The proposed solution seems reasonable. This will also remove uncertainty from Virgo which is now not in a good position to police this invariant separately from the Equinox region bundle. (In reply to comment #2) > I agree that it would be good to establish this invariant. Knowing that the > combination of region id, bundle symbolic name, and bundle version is > sufficient, within a given framework, to uniquely identify a bundle is a very > useful property. > > The proposed solution seems reasonable. > > This will also remove uncertainty from Virgo which is now not in a good > position to police this invariant separately from the Equinox region bundle. Note that this invariant can only be enforced if Region.installBundle is used. Any code using BundleContext.installBundle will still have the ability to install duplicate BSN/versions. This is because a hook cannot cause the installation to fail, except in the very special case where a duplicate location string is detected. In this case should we cause the newly installed bundle from BundleContext.installBundle to be isolated such that nobody can see it. This would be pretty strange because from the installer's point of view it will look like the bundle got installed fine. In that case, we wouldn't have an invariant at all as it could be broken by BundleContext.installBundle. I don't think a mere pre-condition check on Region.installBundle is worth the overhead. I don't like the option of hiving off the bundle and pretending the install was ok as that will just cause confusion for users. So, to implement this bug properly, I think we need a bundle lifecycle hook with the ability to fail bundle install. (In reply to comment #4) > In that case, we wouldn't have an invariant at all as it could be broken by > BundleContext.installBundle. I don't think a mere pre-condition check on > Region.installBundle is worth the overhead. That is where I was headed. So the fix to this bug for now is to remove the pre-condition check on Region.installBundle javadoc. > > I don't like the option of hiving off the bundle and pretending the install was > ok as that will just cause confusion for users. > > So, to implement this bug properly, I think we need a bundle lifecycle hook > with the ability to fail bundle install. Agreed. For now we cannot address this issue. If we feel it should be fixed then we need to get a core enhancement to the spec. Sigh, it is too bad we did not think to do the same trick we do for duplicate bundle locations for the duplicate BSN/Version check. If only we had spec'ed that the framework must call bundle FindHook.find method to determine if the installing context could see the existing bundle with the same BSN/Version as the bundle being installed. Perhaps that is what we can do when/if the specification decides to make org.osgi.framework.bsnversion=multiple as the default. (In reply to comment #6) > Sigh, it is too bad we did not think to do the same trick we do for duplicate > bundle locations for the duplicate BSN/Version check. If only we had spec'ed > that the framework must call bundle FindHook.find method to determine if the > installing context could see the existing bundle with the same BSN/Version as > the bundle being installed. > > Perhaps that is what we can do when/if the specification decides to make > org.osgi.framework.bsnversion=multiple as the default. Let's discuss this topic in the CPEG. Meanwhile, I agree we should fix this bug by changing the javadoc. I removed the javadoc statement about checking for duplicate bsn/version. (In reply to comment #7) > Let's discuss this topic in the CPEG. I opened CPEG bug https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2020 |