>>> What happens when Bundle.update is called, but the new bundle data has a >>> different Bundle-Version? Does it result in an exception? I would expect >>> it >>> to, since a Bundle-SymbolicName and Bundle-Version combination uniquely >>> identifies a bundle instance. >>> >> >> Well, during an update the bundle is first stopped, then updated and >> the new version is started. It shouldn't result in an exception if you >> update a bundle to a different version number. >> >> 4.3.10 Updating Bundles >> ... >> The update process supports migration from one version of a bundle to a >> newer version of the same bundle. The exports of an updated bundle must >> be immediately available to the Framework. If none of the old exports are >> used, then the old exports must be removed. Otherwise, all old exports >> must >> remain available for existing bundles and future resolves until the >> refreshPackages method is called or the Framework is restarted. >> >> > > Kind of confusing. How does a user get the new org.osgi.framework.Bundle > object? Bundle.update() returns void and a bundle's BundleId remains same > even after update (it's defined that way in the spec). If the old > org.osgi.framework.Bundle object now points to the new bundle, how do I get > to the bundle with the old Bundle-Version, if at all I need to.
The Bundle object for a given bundle id is always the same -- hence, you can use the same object to get access to the new revision. You can't, however, reach the old revision anymore. When the bundle is updated it is updated. regards, Karl >>> If the spec expects users not to change >>> Bundle-Version while calling update, then I fail to see how it is used in >>> a >>> proper version controlled environment. >>> >> >> Where does it say so in the spec? >> > > No, the spec does not say so, nor does it say the opposite. That's why I > used "if". I am trying to find out the intention. > > >>> My understanding is that Bundle-Version is an implementation version, >>> hence any time a user changes >>> anything in the bundle, be it a manifest update or some bug fix, in a >>> proper >>> version control environment, the new bundle should have a different >>> Bundle-Version. >>> >> >> I agree and that should be possible. >> >> > > Thanks for stating your opinion, and I am glad we agree on this point. I am > also interested to know use cases of updating the bundle without updating > the Bundle-Version in production environment. > > Thanks, > Sahoo >> >> regards, >> >> Karl >> >> >>> >>> Thanks, >>> Sahoo >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
