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 <pa...@a2zliving.com> 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 <pa...@a2zliving.com> 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 <pa...@a2zliving.com> 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
>>>>> osgi-dev@mail.osgi.org
>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>> _______________________________________________
>>>> OSGi Developer Mail List
>>>> osgi-dev@mail.osgi.org
>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
