Hi, I will try the blueprint approach. Thanks a lot.
Leen On Fri, Nov 19, 2010 at 8:38 AM, Achim Nierbeck <[email protected]> wrote: > Just to give you one more opportunity. > Use Blueprint, or Spring-DM (guess two opportunities :) ) > These frameworks make sure that your bundle isn't loaded until your > configuration is available. > > greetings, Achim > > 2010/11/19 Felix Meschberger <[email protected]> > >> Hi, >> >> There is another glitch: the Configuration Admin Service may not >> available at all at the time your BundleActivator is called. So you >> would have to -- for example -- use something like a ServiceTracker (or >> better revert to using something like Declarative Services which gives >> you more control while at the same time removing the requirement to rely >> on OSGi API) to track the Configuration Admin Service. >> >> Re Declarative Services (DS): As of the latest specification you can >> configure the components acting as services to only be activated and >> thus registered as services once configuration is available. DS also >> offers you the ability to have "default configuration" should a >> Configuration Admin configuration not be available. >> >> Regards >> Felix >> >> Am Freitag, den 19.11.2010, 00:38 +0100 schrieb Marcel Offermans: >> > That won't work: the fact that the configuration admin service is >> available does not mean there will be a configuration available for you. And >> even if there is, there will still be all kinds of timing issues. >> > >> > If your service needs to be configured before it can be used, don't >> publish it until you got a valid configuration. >> > >> > Greetings, Marcel >> > >> > On 18 Nov 2010, at 17:32 , Wunden Tobias wrote: >> > >> > > Hi Leen, >> > > >> > > in the activator, you could ask the service registry for the config >> admin service and explicitly get the configuration from it, then using it to >> make a call to the updated() method of the ManagedService interface >> yourself. >> > > >> > > Make sure to add a reference to the config admin, otherwise your >> service might be started before it is available. The downside with that will >> be that your service goes down when the ConfigurationAdminService does. >> > > >> > > Tobias >> > > >> > > On 18.11.2010, at 17:24, "Leen Toelen" <[email protected]> wrote: >> > > >> > >> Hi, >> > >> >> > >> I have some trouble understanding the correlation between FileInstall >> > >> and ManagedServices. >> > >> >> > >> This is an activator: >> > >> public void start(BundleContext context) throws Exception { >> > >> MyImpl impl = new MyImpl(); //implements two interfaces, one of >> > >> which managedservice >> > >> >> > >> Properties properties = new Properties(); >> > >> properties.put(Constants.SERVICE_PID, "myservicepid"); >> > >> String[] interfaces = { ManagedService.class.getName(), >> > >> MyInterface.class.getName() }; >> > >> context.registerService(interfaces, impl, properties); >> > >> } >> > >> >> > >> and under my fileinstall managed directory I hava myservicepid.cfg >> > >> with key-value pairs in it. >> > >> >> > >> The question is when the services are registered and available to >> listeners. >> > >> - when the activator is started >> > >> - after fileinstall is calls updated(Dictionary) on the ManagedService >> > >> (using ConfigurationAdmin) >> > >> >> > >> should the implementation check whether is has been configured or not, >> > >> or does felix do this for me? If not, is there a way to only register >> > >> myImpl as "MyInterface" after it has been configured? >> > >> >> > >> Regards, >> > >> Leen >> > >> >> > >> --------------------------------------------------------------------- >> > >> 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] >> > > >> > > >> > >> > >> > --------------------------------------------------------------------- >> > 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
