On Tue, Jan 24, 2017 at 2:17 PM, Tim Jones <tim.jo...@mccarthy.co.nz> wrote:
> Actually the remote service still calls the same 'top level' component but > it is this component that will make the choice as to which set of instance > of services are ultimately exercised. At the risk of going too far off > topic but to illustrate the requirement, the application is a multi-tenant > system that needs to be able to create and access new db schemas on the > fly. I don't wont the call to create the new db schemas and the associated > services to return until they have been created. > A nice way to do this is to flip the problem on it's head and manifest the schemas, once ready, as a services and have interested components declare references to those services. - Ray > Tim > > > > ------------------------------ > *From: *"Christian Schneider" <ch...@die-schneider.net> > *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > *Sent: *Wednesday, 25 January, 2017 11:01:20 AM > > *Subject: *Re: [osgi-dev] How to determine when a new service instance > has been activated? > > 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 > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
