If memory is of concern, stopping might not help since you do not know what these bundles hang on to.
Best way is to use DS in lazy mode and refresh all bundles. In a well designed
OSGi system this should be painless and is guaranteed to clean up since the
class loaders are thrown away.
Kind regards,
Peter Kriens
Even if you're the MA, I would make sure that the MA does this garbage
collecting.
On 1 okt. 2014, at 18:23, Tim Diekmann <[email protected]> wrote:
> Well, I am implementing the MA, so I am the authority to call start/stop,
> nobody else can do that. This should cover that part.
> I want to use start/stop, because I want the bundles out of memory when
> stopped. I don’t want objects to linger in memory when not used.
>
> I don’t see how having two trackers will fix the issue, since they will both
> need to be looking for the same header and operate on the same bundle. Now,
> it’s worse, because they are not coordinated and the order of callback is
> arbitrary.
>
> Thanks for your comments, Peter. I knew you would answer and try to help.
>
> Tim.
>
> On Sep 30, 2014, at 11:49 PM, Peter Kriens <[email protected]> wrote:
>
>> Why not split this in 2 trackers? One for the start/stop and one for the
>> Extender?
>>
>> <soapbox>
>> The start/stop state of a bundle is singleton, you can only use it once.
>> These methods are uniquely reserved for the management agent (MA). Once you
>> get in scenarios where the start/stop is abused by others than the central
>> singleton management agent you create a hard to manage system since now the
>> start/stop state of a bundle gets different meanings. To keep things simple,
>> the MA controls start/stop, an extender ONLY reacts on ACTIVE bundles. E.g.
>> in your case you indicate that you're interested only in bundles with a
>> given header. By using the start/stop method you make it impossible for
>> anybody else to use start/stop reliably because it will interfere with these
>> 'special' bundles.
>>
>> I know how attractive it is to abuse the start/stop methods but every time
>> I've used it or seen it used people regret it because it is a singleton and
>> later find out their way is not compatible with other people's way. Look at
>> the awful model Eclipse has with not starting their bundles. You just create
>> self inflicted pain.
>>
>> KISS!
>>
>> </soapbox>
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> On 1 okt. 2014, at 02:24, Tim Diekmann <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> I’m looking for a solution, but cannot come up with one. Here is the
>>> scenario:
>>>
>>> I have a BundleTracker to track bundles with a certain header, i.e.
>>> implementing an extender. The extender is interested in
>>> RESOLVED|STARTING|ACTIVE|STOPPING.
>>>
>>> When a bundle is installed, but not started, the addingBundle() is called
>>> and the extender processes the bundle. Now, I want to start the bundle
>>> based on whether it is configured to be started or not, i.e. I am looking
>>> at CM configuration to determine whether to start the bundle or not.
>>>
>>> Now, here’s the problem: You cannot start the bundle in the callback of
>>> BundleTrackerCustomizer.addingBundle().
>>> If you do, the bundle will start, but your Tracker will not receive any
>>> events for the Bundle, since it hasn’t returned yet from the addingBundle()
>>> callback to indicate interest in the Bundle.
>>> What I need here is to be able to return from the addingBundle() callback
>>> to indicate interest and then trigger the start of the Bundle.
>>>
>>> How do I do that?
>>>
>>> This is event driven. The callback to addingBundle() is the main event.
>>> Now, I need another event that the bundle is tracked in order to trigger
>>> the start such that the same extender BundleTrackerCustomizer starts
>>> receiving the events for the start of the Bundle.
>>>
>>> Any ideas, anyone?
>>>
>>> Thanks,
>>>
>>> Tim.
>>>
>>> P.S: I doubt that setting the start level would help here. Since the
>>> BundleTrackerCustomizer.addingBundle() call hasn’t returned yet, it will
>>> not receive any events for the Bundle. Even if the start level is changed
>>> by another thread, there is no guarantee that the BundleTracker returns
>>> before the start level thread starts the bundle.
>>> _______________________________________________
>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
