"I refreshed both the xml bundle and the bundle containing the implementation and the web service was still getting the old implementation."
Could you please submit a list of all bundles that you have put in to the system. I'm sadly still having trouble understanding your env (sry, I don't work with Spring). :( If I assume the following osgi framework fileinstall xml-bundle spring-bundle I need to know where the "bundel containing the implementation" is and also where the "web service bundle" is. Maybe if I knew more about spring I would be able to figure it out but... It is important to know to get a clear picture of what depends on what. Generally though, if I assume that the web service is a bundle separate from xml and spring and that the spring bundle is the bundle containing the implementation, I get the following: osgi framework bundle fileinstall xml-bundle spring-bundle web service-bundle and then I also guess the dependencies (on package level but nevermind at this point) look like xml-bundle : no export, no import spring-bundle: export org.spring, no import web service: no export, import org.spring Then updating the xml-bundle will be completely transparent to all other bundles. Updating the spring-bundle and refreshing will affect the web-service bundle (unless it was wired to some other bundle exporting org.spring but that is unlikely). Updating the web service-bundle will not affect any other bundle. With this I'm just trying to say that it would be easier to explain things if we knew your dependency graph, or at least the relevant parts of it. If you know your dependency graph then maybe the following can be helpfull: http://www.osgi.org/javadoc/r2/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]) It explains what the framework does when a bundle is refreshed. Maybe, depending on your dependency graph, the bundle you need to refresh is the web service-bundle (if that is even a bundle, I'm really not sure about your system). Also note in the link that you can refresh all bundles by specifying null to package admin. Also note that this migth restart the entire framework, however I don't think any of the big dists of osgi does that (felix, equinox, knopflerfish) so it should be a feasable way to test this. Basically, what you want to do should be possible, unless you have some strange class-loading that somehow circumvents the export-import or a dependency graph that contain elements that we don't know of. Finally, if you're having trouble with this, instead of updating, try and uninstall and install the bundle that had a bug. This is semantically different than an update (which is why Richard asked if you had done a refresh). Currently, my guess is that you either have no dependencies on the bundle that you updated (no one depends on it) or that you load classes from that bundle while somehow circumventing the bundle classloaders. A third less plausible explanation is that whatever package that you export from the bundle you updated are imported by others from some other place (so in effect no one depends on the bundle you updated). Forthly, and maybe most likely, I'm misinterpreting your dependency graph. Regards Per-Erik Svensson On Tue, Aug 16, 2011 at 1:04 PM, [email protected] <[email protected]>wrote: > Was the application context refreshed when you refreshed the xml bundle? Is > there any logs after refresh? > > > On 16.08.2011 14: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. >> >> 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] > >
