Yes, that's perfectly doable. We've implemented that in Karaf 4.0. You need to use karaf features for that. Bundles will be uninstalled when no longer required in a very reliable way because it uses the OSGi resolver to actually compute the wiring.
Guillaume 2016-06-15 13:18 GMT+02:00 Paul F Fraser <[email protected]>: > Thanks Marcel, Neil and Peter, > > From Peter's comment > > "I think it is incredibly hard to do this reliably with the extensive > requirement capabilities of OSGi" > > Is this why Aries subsystems have a phase where bundle versions are locked > in for deployment of the subsystem? > > Paul > > > > > On 15/06/2016 8:46 PM, Peter Kriens wrote: > > You’re entering dangerous waters … I think it is incredibly hard to do this > reliably with the extensive requirement capabilities of OSGi. > > I assume you want to garbage collect bundles. The best solution I know to > this problem is to make a feature == a list of requirements. If such a > feature is added/removed you resolve the list of features as the initial > requirements. You then remove the bundles that are not part of the resolution > and install the bundles that were missing. > > I would strongly advice trying to do this with simple heuristics. > > Kind regards, > > Peter Kriens > > > > On 15 jun. 2016, at 12:39, Paul F Fraser <[email protected]> > <[email protected]> wrote: > > Actually I probably should be talking about required count. > > Feature A requires bundle 1, 3 and 5 > Feature B requires bundle 3, 5 and 7 > Feature C requires bundles 1 and 8 > > bundle 1 is required by 2 features > bundle 3 is required by 2 features > bundle 5 is required by 2 features > bundle 7 is required by 1 features > bundle 8 is required by 1 features > > if feature C is stopped bundle 8 can be stopped and possibly uninstalled > bundle 1 count drops to 1 but remains running to serve Feature A > > Paul > > > On 15/06/2016 8:28 PM, Neil Bartlett wrote: > > On 15 Jun 2016, at 11:19, Paul F Fraser <[email protected]> > <[email protected]> wrote: > > Hi, > > The bundle usage counting is required for a simple feature start and stop > functionality. > > Okay but we still haven’t got to the bottom of what you mean by “usage”. > > > If a bundle is used by multiple features I need a count to know when to > install and start a bundle … > > This sounds like you want to know whether a bundle *would* be used before you > install/start it. OSGi cannot tell you that. You might be able to use the > resolver tooling in bnd to predict what the runtime wiring might look like, > but it’s not guaranteed to match what the framework will actually do. > > > … and when features are stopped to detect when to stop and or uninstall a > bundle. > > So, if a bundle has no provided wires and no consumed services then it’s > probably pretty safe to uninstall. > > Neil > > > Paul > > On 15/06/2016 8:00 PM, Neil Bartlett wrote: > > Depends what you mean by "bundle usage". > > If you’re talking about services, then you can get the ServiceReferences > registered by a bundle and count the using bundles with getUsingBundles. If > you’re talking about package wiring and Require-Bundle then you can adapt the > bundle to a BundleWiring object and call getProvidedWires. Bear in mind that > there will be duplicates and the bundle could also wire to itself (or > reference its own services). > > Neil > > > On 15 Jun 2016, at 10:53, Paul F Fraser <[email protected]> > <[email protected]> wrote: > > Hi, > > Is there an existing ability in the OSGi environment to keep a bundle usage > count? > > It is not difficult to create my own method and storage, but if something > already exists! > > I did think I could use the Bundle data area but it seems that different > frameworks lay it out differently. > > Aries subsystems has bundle counting but it is a bit heavy for my use case. > > Any suggestions? > > Regards > > Paul Fraser > > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
