Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

I’m not sure if my suggestion would continue to work i R7 due to coordination support. david jencks > On Jan 9, 2017, at 11:46 AM, David Jencks wrote: > > Felix DS runs off the configuration events too, so just waiting for the > events isn’t going to determine

Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

Hi Tom, Let me start with saying that I'm not sure if the approach works with DS components but we use Amdatu Testing for our tests, that has an option for synchronous delivery of configurations [1]. This synchronous delivery mode bypasses ConfigAdmin and applies configuration changes directly to

Re: DS 1.3 Components from different bundle using same configurationPid are not all updated

There is no bug in DS here. In order to use a configuration with more than one bundle, you need to arrange that the configuration location be a multi-location. normally you’d want “?” so any bundle can receive the configuration. AFAIK fileinstall doesn’t support setting the location, so the

Re: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

Felix DS runs off the configuration events too, so just waiting for the events isn’t going to determine whether you or DS is notified first. I’m not sure if you can use serviceRanking to determine which configuration listener gets notified first. If you can arrange that your listener is called

RE: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

We started with Amdatu testing, but we've forked off now and use something similar but different. That method of synchronous config delivery would be hard with DS I think. Maybe doable if there is an @Modified method, but much harder if not, having to deactivate and reactivate the component.

RE: Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

> I’m not sure if my suggestion would continue to work i R7 due to coordination > support. Sorry, expand please? - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail:

Config admin: when do the CM_UPDATED, CM_DELETED events actually get called?

I'm trying to use the CM_UPDATED and CM_DELETED config admin events in a test harness to ensure that a configuration change has been actioned before the test case gets run, but I'm unclear when exactly these get called. The OSGi specification doesn't seem very enlightening. "An event is fired

DS 1.3 Components from different bundle using same configurationPid are not all updated

Hi, I am using DS @Component and trying to get notified through @Modified when a shared pid file is updated (using felix scr 2.0.2 in karaf 4.0.5) I defined a configuration interface such as: @ObjectClassDefinition(pid = "foo.bar") public @interface MyConfig { String username() default

Re: DS 1.3 Components from different bundle using same configurationPid are not all updated

Hi, I think this should be possible the way you do it, so that's a "yes" to the first two of your questions at the end :) Before we start to look for a bug in the implementation, could you please check the scr 2.0.6 release and see whether it's already fixed there? If not, please open a jira

Re: DS 1.3 Components from different bundle using same configurationPid are not all updated

Hi Carsten, Thanks for your quick answer. I've just tested with latest karaf 4.0.8 which ships with scr 2.0.6 => It is working now without changing any piece of code. It seems that a fix has been provided between 2.0.2 and 2.0.6. Thanks for you advice Kind Regards, Christian On Mon, Jan 9,

Re: DS 1.3 Components from different bundle using same configurationPid are not all updated

Hi, I did more tests and I noticed the following behavior with karaf 4.0.8 and scr 2.0.6 (which does not occur with karaf 4.0.5 and scr 2.0.2). Having a simple pid defined as: @ObjectClassDefinition(pid = "foo.bar") public @interface MyConfig { String username() default "myuser"; String