felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-5200) Factory Configuration Adapter Not Retarted
Date Sat, 27 Feb 2016 17:05:18 GMT
Pierre De Rop created FELIX-5200:

             Summary: Factory Configuration Adapter Not Retarted
                 Key: FELIX-5200
                 URL: https://issues.apache.org/jira/browse/FELIX-5200
             Project: Felix
          Issue Type: Bug
          Components: Dependency Manager
    Affects Versions: org.apache.felix.dependencymanager-r1
            Reporter: Pierre De Rop
            Assignee: Pierre De Rop
             Fix For: 	org.apache.felix.dependencymanager-r7

When a factory pid adapter is losing one of its required service dependencies, it is stopped,
but when the lost dependency comes up again, the configuration adapter instance is not re-created
and re-started.


 * A factory configuration adapter has a required dependency on a "Required" service.
 * The factory configuration is created, the "Required" service is registered, so a factory
configuration adapter INSTANCE1 is then created.
 * Now the "Required" service is unregistered: the INSTANCE1 is then stopped.
 * And when the "Required" service comes up again, then a new factory config adapter INSTANCE2
should be re-created, updated and started, But since R1 this is not the case anymore.

The bug is located in the AbstractDecorator.stop() method, this method currently does this:

    public void stop() {
        for (Component component : m_services.values()) {

Clearly, this is a bug because the "m_services" list is not cleared, so when the AbstractDecorator.updated(String,
Dictionary) method is called again, it finds again some old stale components, and updates
them instead of re-creating new adapter instances.

In DM3, the list was correctly cleared:

    public void stop() { 
        Object[] components;
        synchronized (m_services) {
            components = m_services.values().toArray();
        for (int i = 0; i < components.length; i++) {
            m_manager.remove((Component) components[i]);

I will add a test case soon.

This message was sent by Atlassian JIRA

View raw message