[
https://issues.apache.org/jira/browse/FELIX-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563321#comment-14563321
]
David Bosschaert commented on FELIX-4883:
-----------------------------------------
[[email protected]], [~lbyrum], in general in the Felix codebase there are no
locks held when calling into custom code (i.e. listeners) as you have no idea
what this code is doing; if custom code is called while holding a lock this may
increase the chances of deadlock situations. I'm not sure whether it's a good
idea to change this.
Wrt to the ServiceTracker being incorrect. It might be good to take this
discussion to [osgi-dev|https://mail.osgi.org/mailman/listinfo/osgi-dev] or
[osgi bugzilla|https://osgi.org/bugzilla/]. The ServiceTracker class in scr is
actually a copy of the
[org.osgi.util.tracker.ServiceTracker|https://osgi.org/javadoc/r5/core/org/osgi/util/tracker/ServiceTracker.html]
class developed by OSGi and since this is quite a complex class it might be
better to discuss it where the original authors can participate.
On the actual symptom. I guess it would do no harm in changing the dto.bundle
assignment to check that getBundle() does not return null. Would this help?
> ServiceComponentRuntime.getComponentConfigurationDTOs NullPointerException
> --------------------------------------------------------------------------
>
> Key: FELIX-4883
> URL: https://issues.apache.org/jira/browse/FELIX-4883
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Environment: Linux, Sling, Adobe CQ, org.apache.felix.scr version
> 1.8.3-R1658944
> Reporter: Rob Ryan
> Assignee: David Bosschaert
> Priority: Minor
> Fix For: scr-2.0.0
>
> Attachments: scrtest.zip
>
>
> In our test automation we install a large set of bundles after our also large
> 'main' app starts up. This causes significant churn as bundles and components
> are stopped and potentially new versions are started. Unfortunately the coded
> involved is not open source, so I cannot deliver the full data required to
> reproduce the failure described here.
> What I can share is that after all this churn of bundles and components being
> stopped and started the ScrComponentRuntime service starts to fail with a
> NullPointerException in getComponentConfigurationDTOs. This was initially
> noticed as an NPE being reported when visiting the felix console at
> /system/console/components.
> The stack at the point of failure is:
> java.lang.NullPointerException
> at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(ServiceComponentRuntimeImpl.java:205)
> at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.satisfiedRefManagersToDTO(ServiceComponentRuntimeImpl.java:169)
> at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.managerToConfiguration(ServiceComponentRuntimeImpl.java:145)
> at
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.getComponentConfigurationDTOs(ServiceComponentRuntimeImpl.java:119)
> at com.robr.incqtest.test.ScrTest.test(ScrTest.java:37)
> ...
> The NPE occurs because a
> org.apache.felix.framework.ServiceRegistrationImpl.ServiceReferenceImpl being
> processed in
> org.apache.felix.scr.impl.runtime.ServiceComponentRuntimeImpl.serviceReferenceToDTO(org.osgi.framework.ServiceReference<?>)
> line: 205
> has a m_svcObj of null. So even though the bundle is actually available in
> the object the getBundle() method returns null.
> [~cziegeler] [~bosschaert] I can investigate further to ideally narrow this
> down further, but any pointers would be much appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
