"If there are dependencies, then it should refresh." Does this hold true even if one of the bundles that is in the "refresh-graph" throws an exception when it is stopped?
Or am I not reading the log correctly? "[...] 13:52:18,909 | ERROR | elixPackageAdmin | RunnableTimedExecution | oncurrent. RunnableTimedExecution 109 | 94 - org.springframework.osgi.extender - 1.2.1 | Closing runnable for context OsgiBundleXmlApplicationContext(bundle=mystuffUserdataLoad, config=osgibundle:/META-INF/spring/*.xml) did not finish in 10000ms; consider taking a snapshot and then shutdown the VM in case the thread still hangs [...]" Regards, Per-Erik Svensson On Tue, Aug 16, 2011 at 5:00 PM, Richard S. Hall <[email protected]>wrote: > On 8/16/11 6:56, Jim Talbut wrote: > >> The xml-bundle does not contain code - but it does contain instructions >> that tell Spring to instantiate objects (and thus to load classes). >> >> "it" is the xml-bundle. >> The xml-bundle instructs spring/camel/cxf to set up a web service, when I >> call that web service I was getting the old implementation. >> >> I refreshed both the xml bundle and the bundle containing the >> implementation and the web service was still getting the old implementation. >> When the xml-bundle was uninstalled (by deleting the file) and reinstalled >> (by copying the same file back in place again) it picked up the new >> implementation. >> > > If one bundle has a dependency on another, then it will be refreshed when > the providing bundle is refreshed (unless there is a bug). A simple test is > to get yourself to the point where you think the refresh is necessary, then > use the Gogo shell "inspect" command to see if there are any dependencies on > the bundle you want to refresh. You could check to see if any bundle is > importing from your bundle using "inspect p c <bundle-id>" or bundle > dependencies with "inspect b c <bundle-id>" or conversely from the dependent > bundle you can query its package requirements with "inspect p r <bundle-id>" > and its bundle requirements with "inspect b r <bundle-id>". > > If there are dependencies, then it should refresh. > > -> richard > > > >> Jim >> >> >> -----Original Message----- >> From: Per-Erik Svensson >> [mailto:pererik.svensson@**gmail.com<[email protected]> >> ] >> Sent: 16 August 2011 10:47 >> To: [email protected] >> Subject: Re: Help understanding OSGi class loading >> >> So, if the only things in the system are >> >> osgi framework (felix) >> fileinstall >> some code bundle (spring bundle) >> a bundle with an xml file only >> >> And the xml-bundle imports packages that the spring-bundle exports, than >> updating and refreshing the spring-bundle should cause the xml-bundle to be >> "reloaded". However, if the xml-bundle does not contain code, why is it >> important that it gets it's package dependencies rewired? It will not load >> any classes anyway (and shouldn't have any package imports because it needs >> no packages)? I must be missing something of your problem. :) >> >> If the xml-bundle however does contain code (and needs to load classes), >> are you sure that the only one exporting the packages of those classes is >> the spring-bundle. One possiblity is that you have other bundles in the >> system that export the same packages and that you're getting wired to those >> packages instead. >> >> "It didn't pick up the new version of the classes until I deleted the >> Spring file[...]" >> 1. What is "it"? Which bundle are you expecting to see the changes from? >> If it's the xml-bundle, have you confirmed that it's manifest.mf-file states >> that it needs at least one package that ONLY the spring-bundle can give. >> 2. There is no way to unload classes, so if "it" has already loaded the >> classes it is using, it doesn't matter that you update the origin of those >> classes. You also need a refresh which will rewire the package dependencies, >> restart the dependent bundles, and reload the classes. >> 3. Have you made sure that the framework actually gets an update request >> on the spring bundle? Fileinstall only has the info supplied by the OS >> (file-size, file creation date and so on) to go on, and might determine that >> spring-bundleA and spring-bundleB are the same thing (no change, no update). >> >> Finally, trying this in gogo shell might help you see what is wired to >> what and when updates actually happen! >> >> Regards, >> Per-Erik Svensson >> >> >> On Tue, Aug 16, 2011 at 7:08 AM, Jim Talbut<[email protected]**> >> wrote: >> >> I've tried using refresh now (sorry it takes so long to get things >>> done around here) and it made no difference. >>> It didn't pick up the new version of the classes until I deleted the >>> Spring file, waited for fileinstall to pick that up and remove the >>> bundle, copied the file over again and waited for fileinstall to pick >>> that up. >>> Note that this is using a 1.0-SNAPSHOT version of the classes so there >>> is no version number change, if that affects things. >>> >>> Jim >>> >>> -----Original Message----- >>> From: Jim Talbut [mailto:Jim.Talbut@groupgti.**com<[email protected]> >>> ] >>> Sent: 12 August 2011 17:32 >>> To: [email protected] >>> Subject: RE: Help understanding OSGi class loading >>> >>> No I didn't. >>> How does that work with existing instantiated objects? >>> >>> Thanks >>> >>> Jim >>> >>> -----Original Message----- >>> From: Richard S. Hall [mailto:[email protected]] >>> Sent: 12 August 2011 14:44 >>> To: [email protected] >>> Subject: Re: Help understanding OSGi class loading >>> >>> Did you refresh after doing the update? >>> >>> On 8/12/11 4:03 AM, Jim Talbut wrote: >>> >>>> Hi, >>>> >>>> I've just been surprised by the behaviour of karaf/felix and I'd be >>>> >>> grateful for some help understanding how this works. >>> >>>> My code is split into two chunks: >>>> >>>> 1. A compiled bundle. >>>> >>>> 2. A Spring XML file. >>>> My intention is that the Spring file contains all the configuration >>>> >>> relating to the piece of work, whilst the bundle contains the (more >>> static) compiled code - with the intention of being able to >>> update/replace the Spring file whenever I want. >>> >>>> I just found an error in the bundle and uninstalled it, but the >>>> bundle >>>> >>> created for the Spring file is still running. >>> >>>> Does this mean that only OSGi services are dynamically removed, and >>>> if >>>> >>> the Spring file directly references exported classes from a bundle >>> then the classes are only resolved via OSGi when they are loaded? >>> >>>> In which case will restarting the Spring bundle clear it out >>>> adequately >>>> >>> to ensure that it picks up a new compiled bundle? >>> >>>> Thanks >>>> >>>> Jim >>>> >>>> >>>> >>>> >>>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@felix.**apache.org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@felix.**apache.org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@felix.**apache.org<[email protected]> >>> For additional commands, e-mail: [email protected] >>> >>> >>> ------------------------------**------------------------------** >> --------- >> To unsubscribe, e-mail: >> users-unsubscribe@felix.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@felix.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
