Not sure if that's what you see, but the state of the FeaturesService is saved in the bundle associated data directory. So if you install a new bundle and remove the old one, the state would be lost. A workaround would be to *update* the bundle instead of install new / uninstall old.
2014-02-12 21:33 GMT+01:00 Steve <[email protected]>: > Karaf users, > > I realized the scenario I described in my original message might be a > bit complex, possibly obfuscating the issue a bit. This one takes the > "agent" updating itself out of the picture and presents a simpler > scenario that demonstrates the issue. You can think of the "agent" as > a Feature-installed bundle that leverages the container-provided > FeaturesService service. > > 1. A Karaf container is run "clean", and automatically installs > the "agent" Feature via the bootstrap mechanism. The Feature > repository containing the aforementioned "agent" Feature contains two > versions 0.0.1-SNAPSHOT and 0.0.2-SNAPSHOT. The bootstrapping > mechanism takes the newest version and installs it as one would > expect. > > 2. The container can be started/stopped and the FeaturesService, > as used by the "agent", works correctly. The BundleInfo objects > associated with each installed Feature are available > (Feature.getBundles()). > > 3. A new version of the "agent" Feature, 0.0.3-SNAPSHOT, is > added to the Features repository and the "agent" is then instructed to > refresh all repositories (via the same process used by the > "features:refreshurl" shell command - remove/add). > > 4. The next time the container is restarted the installed > Features returned by the FeaturesService no longer have any BundleInfo > objects associated with them; Feature.getBundles() never returns a > List<BundleInfo> that is populated (even when it previously did). > > It seems odd that the modification to the Features repository XML > document would cause the FeaturesService (really the Feature objects > it returns) to lose track of the relationship between all Features > (regardless of repo) and their associated bundles. Any clue as to > what might be the cause of this? > > Any assistance or advice in this matter is greatly appreciated. > > > > Many Thanks, > > -Steve > > > On Wed, Feb 12, 2014 at 11:01 AM, Steve <[email protected]> wrote: > > Karaf users, > > > > I'm experiencing strange behavior of the concrete implementation of > > the org.apache.karaf.features.FeaturesService interface in Apache > > Karaf 2.3.0 (as part of JBoss Fuse 6) - please take a look at my use > > case and see if you might be able to shed some light on what I'm > > experiencing: > > > > I've implemented an "agent" that provisions its host Karaf container > > using Features (as opposed to bundles or KARs). The agent itself is > > also installed/upgraded via the Features mechanism. I've recently run > > into a strange issue when the agent updates itself; specifically, > > after successfully self-updating to a new version (old installs new, > > new uninstalls old) and restarting the container the FeaturesService > > doesn't return Features that have BundleInfo objects associated with > > them. It's worth noting that the problem only materializes after a > > restart; never before. > > As a result, the agent is no longer able to correctly identify its > > encapsulating Feature. I use the following code-fragment to identify > > the Feature(s) which encapsulate the agent application's bundle: > > > > public Set<Feature> getEncapsulatingFeatureSet() { > > Set<Feature> encapsulatingFeatureSet = new HashSet<Feature>(); > > String selfBundleLocation = bundleContext.getBundle().getLocation(); > > > > Feature[] installedFeatureArray = > featuresService.listInstalledFeatures(); > > for(Feature installedFeature : installedFeatureArray){ > > for(BundleInfo bundleInfo : installedFeature.getBundles()){ > > if(selfBundleLocation.equals(bundleInfo.getLocation())){ > > encapsulatingFeatureSet.add(installedFeature); > > logger.info("Encapsulating Feature detected --> " + > > installedFeature.getName() + "/" + installedFeature.getVersion()); > > break; > > } > > } > > } > > > > return Collections.unmodifiableSet(encapsulatingFeatureSet); > > } > > > > This has always worked very well and I haven't had any prior issues. > > However, after restarting post-update the List of installed Features > > returned by FeaturesService.listInstalledFeatures() do not show up as > > having any BundleInfo objects associated with them (for both OOTB and > > custom Features) as retrieved by Feature.getBundles(). > > > > I admit I'm at a loss to explain why I'm receiving what can only be > > described as invalid data (I know these Features should have > > BundleInfo objects associated with them). I'm hoping someone might be > > able to shed some light on why the FeaturesService is seemingly > > behaving strangely (if its operator-error please let me know), and > > then only after a restart. > > > > > > Thank you for your time, > > > > -Steve >
