Use case: A bundle like Preference Service manages persistent storage for other bundles based upon a bundles identity. This bundle needs to know when a bundle for which it managing storage has permanently gone. If bundle ids can be reused, the Prefs bundle would not be able to destroy the original bundle's information and would provide it to the new bundle. The Prefs bundle might not be running at the time the original bundle is uninstalled and thus would not receive the UNINSTALLED event. So it must rely on the fact that the framework guarantees that bundle ids are never reused.
In any case, you can take my word for it, since I was there when all this was first conceived. From the R1 spec: "Once its value is assigned to a bundle, that value must not be reused for another bundle, even if the original bundle is uninstalled." -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 Eric Swindell <[EMAIL PROTECTED]> 2007-08-16 18:34 Please respond to [email protected] To [email protected] cc Subject Re: [jira] Assigned: (FELIX-339) Ensure bundle identifiers never get reused I figured there was a use case somewhere :) However, I'm still not convinced that it's in the spec. I'm not sure it is wise to rely on the consistency of the id in this case. Yes, while the bundles are running within a Framework instance and yes on restarts, but if a Bundle is uninstalled and the Framework instance restarted, I'm not seeing the need nor the spec requirement. I wouldn't even be concerned if the Bundle ids changed after a restart. Eric On Thursday 16 August 2007 05:23:03 pm Marcel Offermans wrote: > On Aug 17, 2007, at 0:05 , BJ Hargrave wrote: > > See section 6.1.4.12 in the spec: > > "Its value is not reused for another bundle, even after a bundle is > > uninstalled." > > Following up on Eric's question. Like BJ says, it's in the spec, and > I actually have a use case for it too. We're tracking life cycle > changes in the framework and in that context we're using the bundle > identifier as an identifier. That means we actually rely on the fact > that this identifier will only refer to one bundle (and describes its > whole life cycle). > > Greetings, Marcel
