If the call is via jms then you should only start the route (and so the jms listener) once the service is injected.
Christian 2017-01-24 22:45 GMT+01:00 Tim Jones <tim.jo...@mccarthy.co.nz>: > Yes the call is made by a component with the injected service and the > service reference is mandatory but the initiating call to the component is > from a remote system e.g. > > Remote system ---- (via Camel/JMS) ----> to component(s) which reference > the newly created service > > Tim > > > ------------------------------ > *From: *"Neil Bartlett" <njbartl...@gmail.com> > *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > *Sent: *Wednesday, 25 January, 2017 9:55:34 AM > > *Subject: *Re: [osgi-dev] How to determine when a new service > instance has been activated? > > Who makes the call to the newly published service? If it is a component > with an injected service, then just make the service reference mandatory. > The component will then not be *able* to call the first service until it is > actually published. > > Most of these timing and ordering problems disappear when you break the > system down into components with injected service references. The DS > runtime takes care of the underlying complexity and gives you a simple > guarantee: for as long as your component is active, it can use its injected > services without worrying about whether they are available yet and/or still > available. > > Neil > > > > On 24 Jan 2017, at 20:42, Tim Jones <tim.jo...@mccarthy.co.nz> wrote: > > Thanks Neil and Christian, > > I may be going about this the wrong way but the service is ultimately > injected into other components as you have suggested Christian. But, I > don't want to return until the target service has been activated (and then > hopefully fairly quickly referenced by other services) as the programatic > call to ConfigurationAdmin.createFactoryConfiguration() is from a remote > system and the next remote call will be to the services that have > references to this newly published/activated service. If the next remote > call is too soon the call would regularly fail as the service would not > have been activated yet. While I acknowledge the next remote call can still > fail I would rather this was the exceptional case. > > Tim > > > > ------------------------------ > *From: *"Neil Bartlett" <njbartl...@gmail.com> > *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > *Sent: *Monday, 23 January, 2017 11:18:54 PM > *Subject: *Re: [osgi-dev] How to determine when a new service instance > has been activated? > > I agree with Christian but would add an exception to his rule… using > ServiceTracker.waitForService() is useful when writing unit tests. The > other options such as adding fixed-length sleeps are unreliable and > seriously damage the performance of your test runs. > > Neil > > > On 23 Jan 2017, at 06:26, Christian Schneider <ch...@die-schneider.net> > wrote: > > This exactly the expected behaviour. The @Activate method allows the > component to configure itself. The service of the component will only be > published when the @Activate method has finished. If it would be published > earlier then the service might be in an invalid state. > > Btw. You should avoid using waitForService. Instead override the > addedService method of ServiceTracker and continue your initialization only > when the service is present. Even better just inject the servcie into > another @Component. > > Christian > > 2017-01-22 21:14 GMT+01:00 Tim Jones <tim.jo...@mccarthy.co.nz>: > >> Hi, >> >> I am after some advice on the following. >> >> In general terms the problem is if a new instance of a service is created >> via a programatic call to ConfigurationAdmin.createFactoryConfiguration(), >> what options do I have to determine that this new service instance has been >> activated considering the call to .createFactoryConfiguration() returns >> immediately. >> >> I have tried setting up a service tracker with a filter for the specific >> instance of the service but I am not sure I understand the expected >> behavior of the .waitForService() method. For a small timeout period e.g. >> 1ms the call to .waitForService() returns with a null service as I would >> expect. For a longer timeout period e.g. 1000ms the call to >> .waitForService() returns with non null service and from the logs I can see >> that it seems to return only after the tracked service has returned from >> the @Activate method, is this the expected behavior? >> >> I also tried adding a sleep for 0.5 sec in the @Activate method of the >> tracked service and the .waitForService() still only returned after the >> @Activate method of that service had returned. Does the registration of a >> service have any dependency on its activation in the context of Declarative >> Services? Note the tracked service has @Component(immediate = true) >> >> Although the behavior is what I am after ie .waitForService() only seems >> to return after the tracked service has activated I am wondering if I am >> just getting lucky in this case. >> >> >> Regards, >> Tim Jones >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> > _______________________________________________ > 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 > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
