I started with a fresh container and created a very basic bundle that
simply prints the number of BundleInfo objects that are associated
with all installed Features. When the start(BundleContext) method is
called on its BundleActivator it simply prints this information to the
log:
public class Activator implements BundleActivator {
private final Logger logger = LoggerFactory.getLogger(getClass());
@Override
public void start(BundleContext context) throws Exception {
ServiceReference[] references =
context.getServiceReferences(FeaturesService.class.getName(), null);
if(references != null && references.length > 0){
logger.info("Located " + references.length + "
FeatureService instances available");
FeaturesService service = (FeaturesService)
context.getService(references[0]);
int bundleCount = getBundleInfoCount(service);
logger.info("Startup bundle feature/bundle mapping count:
" + bundleCount);
service = null;
for(ServiceReference servRef : references){
context.ungetService(servRef);
}
}
}
@Override
public void stop(BundleContext context) throws Exception {
}
private int getBundleInfoCount(FeaturesService service) {
int bundleCount = 0;
Feature[] installedFeatures = service.listInstalledFeatures();
if(installedFeatures != null && installedFeatures.length > 0){
for(Feature installedFeature : installedFeatures){
List<BundleInfo> bundles = installedFeature.getBundles();
if(bundles != null && !bundles.isEmpty())
bundleCount += bundles.size();
}
}
return bundleCount;
}
}
This works fine the first time; on a vanilla JBoss Fuse 6.0 (full)
container it locates 254 BundleInfo objects associated with the OOTB
Features. After the container is shutdown and started up again this
count drops down to 0. The second test I tried was to start a vanilla
container for the first time, shut it down, then start it back up and
install the test bundle. Again, zero BundleInfo objects were
associated with the installed Feature objects returned by
FeaturesService.listInstalledFeatures().
The workaround I have employed is to not rely on
FeaturesService.listInstalledFeatures(); rather, I query for all
available Features and then check their installation status
explicitly. The aforementioned method only seems to work correctly
the very first time the container is started (or after a "clean"). So
while the previous code doesn't work, the following does the trick:
private int getBundleInfoCount(FeaturesService service) {
int bundleCount = 0;
try {
Feature[] availableFeatures = service.listFeatures();
if(availableFeatures != null && availableFeatures.length > 0){
logger.info("Located " + availableFeatures.length + "
available Features");
for(Feature availableFeature : availableFeatures){
if(service.isInstalled(availableFeature)){
List<BundleInfo> bundles = availableFeature.getBundles();
if(bundles != null && !bundles.isEmpty())
bundleCount += bundles.size();
}
}
}
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return bundleCount;
}
When I get a chance I will see if this issue appears in version of
Karaf newer than 2.3.0.
Thanks,
-Steve
On Thu, Feb 13, 2014 at 9:20 AM, Steve <debianclus...@gmail.com> wrote:
> 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 <gno...@apache.org> 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 <debianclus...@gmail.com>:
>>
>>> 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 <debianclus...@gmail.com> 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
>>
>>
