Community
Participate
Working Groups
Build Identifier: 20100218-1602 Two bundles S and C. S provides a declarative service, while C consumes it. (Consumer card=1, policy=static) Both C and S have activator and deactivator methods set for their components. C has set its bind/unbind methods correctly. with "normal" startup, everything works fine. Both components are activated, the DS ist set on the client. Stopping and Restarting either bundle does not affect the correct function. However, after updating the providing bundle S, none of S and C is re-activated. S registers its service, but C cannot retrieve it. DS.Reference.hasProviders() cannot retrieve any service ref by calling "BC.getServiceReferences(Str,Filt)", although it seems that the service is registered. BundleContext.getAllServiceReferences(null,null) contains the service ref though!! I managed to track this down to "Framework.isServiceAssignableTo(Bundle registrant, Bundle client, String className, Class serviceClass)" where it turned out, that the wirings are incompatible (SingleSourcePackage.hasCommonSource returns false) since producer and consumer source' bundle loader proxy (BLP) differ. BLPs are checked for identity here ("=="). Reason: The BC of a ServiceComponent is set upon parsing the declaration (on startup) in "DeclarationParser.doCorrectComponentTag" thus, the scp is referencing an invalid bundle context after a bundle update! Reproducible: Always Steps to Reproduce: Can provide sample bundles and a Launch config if necessary
ad Resaon: checked further, seems that my analysis is not correct. The provider bundle has SCRManager.startedBundle invoked and has the BC of its SCPs updated.
ad: getAllSR finds a service vs. getSR does not: Observed behaviour seems ok in terms of spec. sorry bout that. However the initial problem persists
Equinox does not restart bundle C upon update of S although C depends on S (which provides the decl service interface)- regardless if dep via RQ Bundle or import pack. It does not matter if S content changes or not or if the version of S in manifest.mf is changed. Obviously , the OSGI console CMD "update" does no package refresh. When doing the refresh manually, the DS works fine again. Should have read chapter 4.4.9 in the OSGi core spec.....
Bernhard, thanks for letting us know you got to the bottom of this. Sorry we did not assist in your conclusion. Most committers are busy finishing 3.6 right now. One way to work around this behavior is to put the service interfaces package P (which I assume are being exported by S) in another bundle X and have both C and S import the service interface package P from X. This way you can update the implementation of S without effecting the package wiring of bundle C to package P which is exported by bundle X. Another recommended way is to have bundle S export AND import the service package P. This way when S is updated it will start in a state where it will import the "old" content of package P from the previous generation of bundle S (which is waiting to be refreshed). This way bundle C and the new version of S are still wired to the "old" version of package P until a refresh packages operation is done.
