> On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote: > > Delete the directory called felix-cache??
No, in his second email he says that other bundles are still running that use the old API. So we’re talking about a series of changes made in a running OSGi Framework, and it wouldn’t be a good idea to delete the storage directory underneath a running framework. These changes *should* work. Best guess is that the implementation bundle ships its own copy of the API bundle. As a general rule, you should do a refresh after a series of changes to bundle states (installs, uninstalls or updates). You can do this simply with the “refresh” command in the Gogo shell. In this scenario, a refresh would cause all the bundles that import from the API bundle to stop and revert to INSTALLED state. Regards, Neil > > On Wed, Nov 4, 2015 at 10:42 AM, Neil Bartlett <njbartl...@gmail.com> wrote: > >> >>> On 4 Nov 2015, at 10:37, i...@cuhka.com wrote: >>> >>> I have an API bundle and and implementation bundle. I removed both the >> API and implementation, re-installed the implementation and started the >> implementation. To my suprise the framework was willing to start the >> bundle, even though the API isn't there anymore. It was present, so >> obviously it is using some cached class. >>> >>> I encountered this because I changed the signature of the API, updated >> all bundle versions and redeployed it. The implementation resolved fine, >> but didn't run because it could not find the updated signature. >>> >>> Personally I would have expected the implementation bundle to have >> picked up the changed api, and after uninstalling to not resolve. Is this >> assumption incorrect? >> >> No, this is basically correct. >> >> However your description of the scenario is too vague to be able to tell >> exactly what happened in this case. If you specify which bundles import and >> export which packages, and what you did to those bundles in sequence, then >> we might get somewhere. >> >> Neil >> >>> >>> Maurice. >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
