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 < [ mailto:tim.jo...@mccarthy.co.nz | 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" < [ mailto:njbartl...@gmail.com | njbartl...@gmail.com ] > To: "OSGi Developer Mail List" < [ mailto:osgi-dev@mail.osgi.org | 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 BQ_BEGIN On 23 Jan 2017, at 06:26, Christian Schneider < [ mailto:ch...@die-schneider.net | 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 < [ mailto:tim.jo...@mccarthy.co.nz | tim.jo...@mccarthy.co.nz ] > : BQ_BEGIN 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 [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] -- -- Christian Schneider [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de | http://www.liquid-reality.de ] Open Source Architect [ https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com | http://www.talend.com ] _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] [ https://mail.osgi.org/mailman/listinfo/osgi-dev | https://mail.osgi.org/mailman/listinfo/osgi-dev ] BQ_END _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [ mailto:osgi-dev@mail.osgi.org | osgi-dev@mail.osgi.org ] https://mail.osgi.org/mailman/listinfo/osgi-dev BQ_END _______________________________________________ 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
