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
