[jira] [Updated] (FELIX-6510) NPE within HealthCheck BundlesStartedCheck for bundle without symbolic name

[ https://issues.apache.org/jira/browse/FELIX-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-6510: Summary: NPE within HealthCheck BundlesStartedCheck for bundle without symbolic name (was:

[jira] [Assigned] (FELIX-6510) NPE within HealthCheck BundlesStartedCheck for bundle without symbolic name

[ https://issues.apache.org/jira/browse/FELIX-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-6510: --- Assignee: Carsten Ziegeler > NPE within HealthCheck BundlesStartedCheck for bundle w

[jira] [Resolved] (FELIX-6510) NPE within HealthCheck BundlesStartedCheck for bundle without symbolic name

[ https://issues.apache.org/jira/browse/FELIX-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-6510. - Resolution: Fixed Thanks, I added a null check for symbolic name - according to the spec

Re: [jira] [Commented] (FELIX-6616) Dynamic greedy 1..1 references may activate with no reference service bound

Carsten’s example results in the sequence 1. bind X ranking 1 2. bind X ranking 100 3 unbind X ranking 1 IIRC this is explicitly mandated by the spec. This is a different order than Tom’s example. FWIW I suspect Tom’s situation can arise after component activation if two threads register two mo