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
>>>>
