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
