Guillaume,
The application in question leverages Blueprint Component and imports
the FeaturesService as a container-provided service. Even when the
application is not updated, the mere act of adding a Feature XML
fragment to an existing Features repository XML document and
refreshing via the service triggers the FeaturesService to lose track
of all bundles on the next container restart (even those originating
from different Feature repository XML documents). That leads me to
believe something deeper might be going on.
Thanks,
-Steve
On Wed, Feb 12, 2014 at 3:40 PM, Guillaume Nodet wrote:
> 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 :
>
>> 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 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 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 getEncapsulatingFeatureSet() {
>> > Set encapsulatingFeatureSet = new HashSet();
>> > 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 a
