felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre De Rop <pierre.de...@gmail.com>
Subject Re: [DS] time for 1.8 release?
Date Sat, 26 Oct 2013 10:00:57 GMT
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 <david_jencks@yahoo.com>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 <pierre.derop@gmail.com> 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 <david_jencks@yahoo.com>
> 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 <pierre.derop@gmail.com>
> 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 <david_jencks@yahoo.com
> >> 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 <pierre.derop@gmail.com>
> > 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
> >>>>>
>
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message