Hi Felix Thanks for your help, now it works :-)
Just for curiosity, is it possible to have @Component implementing ManagedFactory so that component has separate configuration PID from that of ManagedFactory? In other words configuration with PID A would be passed to @Activate/@Modified methods and configurations with PID B be passed to ManagedServiceFactory.updated? Best regards On Mon, Jul 29, 2013 at 2:26 PM, Felix Meschberger <[email protected]> wrote: > Hi Martin > > Looking at the SCR code, this should really work: A component with ignoring > configuration policy is not handled if a configuration event arrives whose > service.pid matches the component name. You might want to look at the > ConfigurationSupport.configurationEvent method. > > But you behaviour is probably due to some other effect: Your component is a > Delayed Component. Which means, that the component is instantiated when its > service is required and disposed off when the service is ungot. > > Now, this is what happens, probably: > > * SCR registers component as ServiceFactory service > * ConfigurationAdmin gets the service > * SCR activates the service > * ConfigurationAdmin sends configuration > * ConfigurationAdmin ungets service > * SCR deactivates services > > I suggest you define the immediate=true attribute on the component element to > make the service an immediate service and preventing SCR from deactivating > the service after ConfigurationAdmin used it. > > Regards > Felix > > Am 29.07.2013 um 13:45 schrieb Martin Ždila: > >> Hello >> >> We are using Apache Felix Declarative Services 1.7.0.SNAPSHOT. I have >> question about following configuration: >> >> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"; >> name="SomeName" configuration-policy="ignore"> >> <service> >> <provide interface="org.osgi.service.cm.ManagedServiceFactory"/> >> </service> >> ... >> </scr:component> >> >> If I create multiple configurations of SomeName, where SomeName is >> also factory configuration PID, SCR calls SomeName component activator >> immediately followed by calling its deactivator, for every >> configuration. It is caused probably by providing >> org.osgi.service.cm.ManagedServiceFactory service and I think this >> behavior is buggy. >> >> Properties passed to activator includes only three fields >> (service.pid, component.name, component.id) and all other fields >> present in configuration are hidden, regardless of >> configuration-policy. Behavior is same if I omit configuration-policy >> attribute. >> >> I would expect that configuration should be in case >> configuration-policy="ignore" ignored completely. What I want to >> achieve is to register org.osgi.service.cm.ManagedServiceFactory as >> component but I want SCR to ignore configurations and leave >> configuration manager to pass it to ManagedServiceFactory update >> method. Is this possible? >> >> Note that I really don't want to have multiple components - one for >> every coniguration. I only want to register only one service extending >> ManagedServiceFactory that handles configurations on its own. >> Workaround it to create component that in activator registers >> ManagedServiceFactory manually. >> >> Thanks in advance >> >> Best regards >> -- >> Ing. Martin Ždila >> Senior Analyst / Developer >> >> M-Way Solutions Slovakia s.r.o. >> Letná 27, 040 01 Košice >> Slovakia >> >> tel:+421-908-363-848 >> mailto:[email protected] >> http://www.mwaysolutions.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Ing. Martin Ždila Senior Analyst / Developer M-Way Solutions Slovakia s.r.o. Letná 27, 040 01 Košice Slovakia tel:+421-908-363-848 mailto:[email protected] http://www.mwaysolutions.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
