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]> 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]> 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]> 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 List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
