On Tue, Jan 24, 2017 at 3:00 PM, Tim Jones <tim.jo...@mccarthy.co.nz> wrote:
> Ray can you please explain a little more what you mean by 'manifest the > schemas'? One thing I should have said is we don't know in advance of > server startup as to what schemas will be needed. > > BTW I have read http://www.coding-dude.com/wp/java/liferay/liferay-multi- > tenancy-setup-with-shards/ > That article is a little dated but it's fine :) What I mean to suggest is that rather than having creation of schema be a side effect caused by some method call, it could probably be better modelled by some agent specializing in schema who once it's built a schema exposes it as an OSGi service. This way other components interested in schema can have real service dependencies on those concert services. I hope that is a little more clear. However, I've been slightly confused by the implication of your statement: > we don't know in advance of server startup as to what schemas will be needed My question to that is; isn't that a function of somebody providing one or not Otherwise, I can't see how you'd magically get a schema as a result of a function call? To me that feels a little reverse. I think the schema should arrive and then others who may need it would be satisfied or not. - Ray > > > Tim > > > ------------------------------ > *From: *"Raymond Auge" <raymond.a...@liferay.com> > *To: *"OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > *Sent: *Wednesday, 25 January, 2017 11:20:37 AM > > *Subject: *Re: [osgi-dev] How to determine when a new service instance > has been activated? > > > > 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 > > _______________________________________________ > 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
