Hi PIerre, Looking at the CA spec it looks like CA is supposed to send out CM_LOCATION_CHANGED events even before any properties are set when setBundleLocation is called. I added some code to ignore these events. Note that DS is "reserving" the configurations for (one of) the component(s) that will be consuming them by calling getConfiguration(pid).
I do wonder how the location to something non-null on your configurations before the properties are set. Waiting for the next bug :-) thanks david jencks On Oct 26, 2013, at 3:00 AM, Pierre De Rop <[email protected]> wrote: > Hello David, > > The code we are using to configure our components is old, at at the time we > wrote it, configadmin was not supporting multi-location. But I do agree, we > can now use the "?" multi-location. > > Now, I'm sorry but I'm still seeing another NPE (sometimes, not always): > > 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent: > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering configuration > event to [org.osgi.service.cm.ConfigurationListener, id=102, > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar] > > java.lang.NullPointerException > at > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226) > at > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396) > at > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344) > at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032) > at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002) > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) > at java.lang.Thread.run(Thread.java:722) > > > I'm not sure, but it seems that ConfigAdmin is providing a null dictionary, > when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a > normal behavior ? > > This is strange; perhaps I shall start a new integration test ? > > /Pierre > > > > > On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <[email protected]> wrote: > Hi Pierre, > > This pointed out a logic error I introduced for Felix 3651. I opened > https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found > which I think explains the NPE. Could you check this? > > Could I ask what you are trying to do by setting the bundleLocation to null? > If you want to allow any bundle to receive the configuration you could use > multi-location support and set the location to "?" With the code you have > now, if the configuration is already in use by a DS component, the location > changed event will result in the bundle location being reset back to what it > was. > > thanks! > david jencks > On Oct 25, 2013, at 8:32 AM, Pierre De Rop <[email protected]> wrote: > > > Hi David, > > > > thanks; The fix is fixing the problem :-) > > > > but ... there's now a new different problem: i'm now sometimes getting this > > NPE, after SCR is receiving a CM_LOCATION_CHANGED event: > > > > 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent: > > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering > > configuration event to [org.osgi.service.cm.ConfigurationListener, id=102, > > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar] > > > > java.lang.NullPointerException > > at > > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226) > > at > > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396) > > at > > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390) > > at > > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032) > > at > > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002) > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) > > at java.lang.Thread.run(Thread.java:722) > > > > Perhaps a new jira issue shall be opened ? > > > > I think we are getting a CM_LOCATION_CHANGED event because in our > > application, we populate configuration admin by doing something like this: > > > > Configuration cfg = cm.getConfiguration(pid, null) > > if (config.getBundleLocation() != null) { > > config.setBundleLocation(null); > > } > > > > The setBundleLocation(null) is probably useless, but this leads to a > > CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE. > > > > > > > > > > > > > > On Friday, October 25, 2013, David Jencks <[email protected]> wrote: > >> Hi Pierre, > >> > >> You are so good at writing useful tests!! > >> > >> I found a place to call setTargets(getProperties()) from inside > > ComponentFactoryImpl that would have fewer side effects. Could you see if > > this makes your actual applications work properly? I'm uploading a > > snapshot. > >> > >> many thanks > >> david jencks > >> > >> On Oct 24, 2013, at 6:17 AM, Pierre De Rop <[email protected]> wrote: > >> > >>> Hi David, > >>> > >>> Since this application is complex, I'm not able to provide logs because > >>> there are hundreds of components involved which are not mine, and for > > now, > >>> I'm not able to diagnose the problem. > >>> > >>> But I have created FELIX-4290, and joined to it an integration test which > >>> seems to reproduce the kind of problem I think I'm having in my > >>> application. I also joined the proposed patch. > >>> > >>> I did not have time to test the patch you suggested regarding the > >>> SingleComponentManager.reconfigure method, so let's continue to > > investigate > >>> using the jira issue and the test I attached to it. > >>> > >>> Thanks; > >>> > >>> /Pierre > >>> > >>> > >>> On Thu, Oct 24, 2013 at 12:27 AM, David Jencks <[email protected] > >> wrote: > >>> > >>>> Hi Pierre, > >>>> > >>>> I believe you that this code path doesn't work :-) > >>>> > >>>> I think there should be a less invasive way to fix this. By any chance > >>>> can you get a debug-enabled log from when this problem occurs? It would > >>>> help confirm my suspicions of what might be missing. > >>>> > >>>> FWIW I suspect SingleComponentManager.reconfigure is missing a check for > >>>> m_factoryProperties here (line 561): > >>>> > >>>> // nothing to do if there is no configuration (see FELIX-714) > >>>> if ( configuration == null && m_configurationProperties == > >>>> null ) > >>>> { > >>>> log( LogService.LOG_DEBUG, "No configuration provided (or > >>>> deleted), nothing to do", null ); > >>>> return; > >>>> } > >>>> > >>>> Unless we can't figure anything out for sure I'd prefer to fix this > > before > >>>> the release. > >>>> > >>>> thanks > >>>> david jencks > >>>> > >>>> On Oct 23, 2013, at 3:09 PM, Pierre De Rop <[email protected]> > > wrote: > >>>> > >>>>> Hi David, > >>>>> > >>>>> (sorry to do all this noise while you are releasing ...) > >>>>> > >>>>> We are indeed using factory components; and today, I finally found and > >>>>> fixed a cycle, using the Apache Service Diagnostic tool; and I'm going > >>>>> further on but now I'm facing another problem which I did not have in > > the > >>>>> scr 1.6.2. > >>>>> > >>>>> So, I would like to discuss about this new problem with you before you > >>>> redo > >>>>> a release, in order to decide if this problem (if there is really one > > ?) > >>>>> shall be addressed now or after the upcoming release ? > >>>>> > >>>>> So, in our application, we are extensively using factory components > >>>>> (@Component(factory=XXX")). > >>>>> When we instantiate a factory component (using > >>>>> ComponentFactory.newInstance()), We pass to the newInstance() method > > some > >>>>> additional component properties which may also contain some target > >>>> filters. > >>>>> > >>>>> This allows to dynamically configure the filter of some References > >>>> declared > >>>>> in the factory component. > >>>>> in the scr 1.6.2, this mechanism was working fine. But using trunk, > > this > >>>>> does not work all the time. Some target filters seem to be correctly > >>>>> configured, and some others are not (I'm not sure, actually, it's late > >>>> ...). > >>>>> > >>>>> So, it looks like sometimes, some target filters are not updated before > >>>>> activating components ? or factory components ? > >>>>> > >>>>> I'm not sure but this might be related to the old FELIX-3726. > >>>>> Now, interestingly, I did the following patch and my application is now > >>>>> working fine: In the AbstractComponentManager class, I systematically > >>>>> update target filters, like this: > >>>>> > >>>>> +++ > >>>>> > >>>> > > src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java > >>>>> > >
