The pattern you are looking for is not handling optionality and dynamics in
your code, but leave this part up to DS. DS' static life cycle is:
bind services // get your dependencies
activate // build up your model
... // do work
deactivate // tear down the model
unbind services // release your dependencies (can be ignored in
static mode)
In this model, your application is created completely in the activate method
and destroyed completely in the deactivate method. Just keep it very simple. DS
is really rock solid and very easy to use. You just have to learn to go with
the defaults. This makes very simple robust systems. I would not even dream
optimizing this until I had performance data.
The surprising thing is that if you just use static dependencies your overall
system is still quite dynamic since the components are activated and
deactivated depending on the state of the system.
The reasons for optionality in DS are mostly to allow your code to run without
a critical dependency, e.g. the Log Service. The reason for dynamics are there
to support discovery use cases. I.e. if you have passenger detection, each
passenger might be represented as a service. In that case you obviously want to
dynamically detect these services.
In your case, a Speed Sensor, seems to imply that your code really needs one to
operate, so static 1:1 seems to be the right choice.
I use DS for all my OSGi code and I rarely use anything else but 1:1 static and
0:n dynamic.
Kind regards,
Peter Kriens
On 9 dec. 2013, at 08:58, Snorre Lothar von Gohren Edwin
<[email protected]> wrote:
> Iv noticed an addition to this question.
> Its also kind comparable to the questions I just passed along about
> updating bundles.
>
> I see that if I dont "reset" the service\api after a start and stop it will
> point to the old implementation of the service.
> Therefor I would say that I would have to reset the reference which i asked
> about in the latter mail.
>
> But this brings me back to the original question.
> Are there any customs or patterns to avoid the resetting, or to do it
> properly?
> I feel that its alot to think of if Im going to to this for all services to
> be able to have it dynamic.
>
>
> On Sun, Dec 8, 2013 at 5:13 PM, Snorre Lothar von Gohren Edwin <
> [email protected]> wrote:
>
>> Haha did not notice that until you pointed out it. Yes im making a machine
>> noticing farts :P.
>>
>> Iv might have been a little fast on the trigger because I had an error
>> which seemed to populate from the service not being callable.
>> But, even if the two instances are different, a class created with a
>> reference to the first instance, will work when the new service arrives
>> aswell. Is this right?
>> It seems to be doing fine.
>> I first thought that since I have different @numbers the reference might
>> be broken, but it doesnt seem this way.
>>
>> In other words its not important to "reset" the api reference in all
>> created objects when reciving the service a secodn time. Is this correct?
>>
>>
>> Another question, if a bundle is stopped, in other word in resolved state,
>> and I have stored the service reference in an object which is created based
>> on the arrival of that service.
>> And i set the service to null, when unSet. Do I manually have to clean up
>> the created object aswell?
>> Because now im experiencing that it is kinda still connected even if the
>> service is gone.
>>
>>
>>
>> On Sun, Dec 8, 2013 at 4:11 PM, Neil Bartlett <[email protected]>wrote:
>>
>>> Aside from the name of your service being hilarious to native English
>>> speakers, I don't see any issue here :-)
>>>
>>> Could you please describe in more detail what the problem is?
>>>
>>> Thanks,
>>> Neil
>>>
>>> On 8 December 2013 at 14:45:49, Snorre Lothar von Gohren Edwin (
>>> [email protected] <//[email protected]>) wrote:
>>>
>>> Hi, im currently developing with DS optional dynamic configurations.
>>> Im experiencing reference issues which have bubbled down in my
>>> application.
>>> Meaning that it holds different instances of the service.
>>>
>>> Providing problems around in the application.
>>>
>>> Example:
>>> At first initiation this is passed around:
>>> fartsensordriver.impl.FartSensorImpl@5cc91eb1
>>>
>>> At reinitiation when the service arrive again, this is passed around:
>>> fartsensordriver.impl.FartSensorImpl@237098e7
>>>
>>> This is ofcourse very logical and understandable.
>>> But im having problems in handling this issue.
>>>
>>> So my question is, are there any patterns or something that exists to
>>> handle this issue?
>>> I believe there is but I would like to ask the experienced OSGi
>>> developers.
>>>
>>>
>>>
>>> --
>>> Mvh
>>> Snorre Lothar von Gohren Edwin
>>> MeetMe: http://doodle.com/vonGohren
>>> +47 411 611 94
>>>
>>>
>>
>>
>> --
>> Mvh
>> Snorre Lothar von Gohren Edwin
>> MeetMe: http://doodle.com/vonGohren
>> +47 411 611 94
>>
>
>
>
> --
> Mvh
> Snorre Lothar von Gohren Edwin
> MeetMe: http://doodle.com/vonGohren
> +47 411 611 94
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
