On Tue, Jan 24, 2017 at 3:08 PM, Raymond Auge <raymond.a...@liferay.com> wrote:
> > > 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. > auto-correct gaf: ...schema 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) > -- *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
