Hi all, and thanks to Pierre for getting me a little further along, I got something sort of working a la Pierre's sample... I originally did not do a runnable, as Pierre has in his Configurator, although I suspect that the runnable is not critical in and of itself... However, the sleep(2) followed by yet another update() seemed to be a critical piece of the riddle... (and, because of the sleep(2), we needed a runnable, obviously);
What I observed is that the "target" MyComponent did not originally receive the initial list of properties as from the Configurator in the first update() method... this is the behavior I was seeing and also saw using Pierre's example... And that was where I originally left things and walked off in frustration... However, Pierre triggered yet another update() invocation, 2 seconds later; That proved to be the critical step; This subsequent update(), 2 seconds later, caused DS/SCR to deactivate my service and reactivate my service, at which point I had almost all the configuration properties (certainly those from the "Configurator" and those from the scr.xml); Interestingly, I lost the config properties from an internal update() method that I was playing with in the MyComponent, which incidentally did show up in the initial configuration (go figure?); So, even with the demonstration as per Pierre, that sort of worked, I'm not satisfied; Which piece or portion is at fault remains to be seen; I don't like that I had to re-trigger an update() 2 seconds later... I don't like that DS/SCR actually deactivated and re-activated the MyComponent bundle... I don't like that DS/SCR registered dozens of obscure PIDs on my behalf (do a cm.listConfigurations()... brutal); And, I don't like that my own bundle's dynamically injected configuration was lost after the 2 second subsequent update(); Again, I don't know who's at fault here, but it aint satisfactory to me. I guess I just don't like the way it's being managed... I'm going to take DS/SCR out of the picture and see what I get... Also, to the iPOJO folks... thumb up to you... I plan to head in that direction... Much appreciate the positive recommendations... And, to all, of course, gratitude to you all, Regards, Craig -----Original Message----- From: Pierre De Rop [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2008 5:24 PM To: [email protected] Subject: Re: declarative services and configuration admin Hi Craig; Here is a sample code showing how to configure a declarative service component, using the ConfigurationAdmin service. Hope this sample code will help you. (But alternatively, you could have a look to the fileinstaller (made by Peter Kriens) which is able to activate bundles and map associated property files to the config admin service: see http://www.aqute.biz/Code/FileInstall) 1/ First, here is a simple component which displays its configuration, once activated: public class MyComponent { protected void activate(ComponentContext context) { System.out.println("MyComponent activated"); System.out.println("properties:"); Enumeration e = context.getProperties().keys(); while (e.hasMoreElements()) { String key = e.nextElement().toString(); System.out.println(key+"="+context.getProperties().get(key).toString()); } } } -> the properties can be configured in SCR.xml, but also using the ConfigurationAdmin service. Here here the corresponding SCR.xml: <component name="MyComponent"> <implementation class="configurable.MyComponent"/> <property name="vendor" value="Alcatel-Lucent"/> </component> SCR will actually register a ManagedService on behald of the "MyComponent" with a PID equals to the component name (that is: name="MyComponent") 2/ Now, here is a sample code which relies on the ConfigurationAdmin service in order to configure the MyComponent service: public class Configurator { private ConfigurationAdmin _cm; protected void bind(ConfigurationAdmin cm) { // we need that service in order to provide config ... _cm = cm; } protected void activate(ComponentContext compctx) { Runnable r = new Runnable() { public void run() { try { Properties p = new Properties(); p.load(new FileInputStream("/tmp/MyComponent.properties")); // you could load all properties found from a specific directory ... Configuration configuration = _cm.getConfiguration("MyComponent", null); configuration.update(p); Thread.sleep(2000); p.setProperty("foo", "bar2"); configuration.update(p); // This update will actually restart (REACTIVATE) the "MyComponent" service } catch (Throwable t) { t.printStackTrace(); } } }; Thread t = new Thread(r); t.start(); // we must not block the SCR thread ... } } and here is the corresponding SCR.xml: <component name="Configurator"> <implementation class="configurator.Configurator"/> <reference name="cm" interface="org.osgi.service.cm.ConfigurationAdmin" bind="bind"/> </component> As you will see, when the Configurator updates the conf (after the short 2 seconds delay), the SCR reactivates the "MyComponent" ! If you would like more information about this, you can refer to http://www.mail-archive.com/[EMAIL PROTECTED]/msg01120.html Kind Regards /Pierre
