Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Wed, 7 Sep 2016 14:09:20 +0000 (UTC)
From: "Pierre De Rop (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12960458.1461181729000.507919.1473257360646@Atlassian.JIRA>
In-Reply-To: <JIRA.12960458.1461181729000@Atlassian.JIRA>
References: <JIRA.12960458.1461181729000@Atlassian.JIRA> <JIRA.12960458.1461181729556@arcas>
Subject: [jira] [Comment Edited] (FELIX-5238) ConfigurationDependency should
 provide the setRequired() method
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 07 Sep 2016 14:09:23 -0000


    [ https://issues.apache.org/jira/browse/FELIX-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260073#comment-15260073 ] 

Pierre De Rop edited comment on FELIX-5238 at 9/7/16 2:08 PM:
--------------------------------------------------------------

Attached a proposed patch. 
I did not commit this since this issue is currently under discussion with the Amdatu team, and for now, I don't have enough +1 to be able to commit.

The patch does the following:

- a setRequired(boolean) method has been added to the ConfigurationDependency interface

- if you invoke setRequired(false) on the configuration dependency, then your "updated" callback is invoked, as before (same lifecycle: before all required dependency callback), except that you will be passed a type-safe configuration interface that is mapped to an empty Dictionary in case there is no available configuration. In this way, you will be able to initialize your component using possibly default methods from the type-safe configuration.

- if then, a configuration is registered, then you will be called in updated, in order to react to the newly registered configuration.

- if, now, the registered configuration is unregistered, you will be called in updated, like in first step, with an type-safe config interface that is mapped to an empty dictionary. So, your component will be reinitialized with default methods possibly declared in the type-safe configuration.

- If you declare a configuration dependency without a type safe configuration, then your updated callback will be invoked with an empty dictionary. Actually, when using an optional dependency configuration, then it is much more better to use a type-safe config with default methods so you can initialize your component with default values. 

See the attached OptionalConfigurationDependencyTest for a real example.

sample code of a Pojo component which defines an optional config dependency:

{code}
    public static interface MyConfig {
        public default String getTestkey() { return "default"; }
    }

   class Pojo {
        void updated(MyConfig cnf) {
             testKey = cnf.getTestKey(); // returns "default" in case there is no configuration
         }
}

createComponent().setImplementation(Pojo.class)
    .add(createConfigurationDependency().setPid("some.pid").setCallbacks("updated", MyConfig.class).setRequired(false));
{code}

I prefer to wait for more feedback from Amdatu team before committing this.


was (Author: pderop):
Attached a proposed patch. 
I did not commit this since this issue is currently under discussion with the Amdatu team, and for now, I don't have enough +1 to be able to commit.

The patch does the following:

- a setRequired(boolean) method has been added to the ConfigurationDependency interface

- if you invoke setRequired(false) on the configuration dependency, then your "updated" callback is invoked, as before (same lifecycle: before all required dependency callback), except that you will be passed a type-safe configuration interface that is mapped to an empty Dictionary in case there is no available configuration. In this way, you will be able to initialize your component using possibly default methods from the type-safe configuration.

- if then, a configuration is registered, then you will be called in updated, in order to react to the newly registered configuration.

- if, now, the registered configuration is unregistered, you will be called in updated, like in first step, with an type-safe config interface that is mapped to an empty dictionary. So, your component will be reinitialized with default methods possibly declared in the type-safe configuration.

- If you declare a configuration dependency without a type safe configuration, then your updated callback will be invoked with an empty dictionary. Actually, when using an optional dependency configuration, then it is much more better to use a type-safe config with default methods so you can initialize your component with default values. 

See the attached OptionalConfigurationDependencyTest for a real example.

sample code of a Pojo component which defines an optional config dependency:

{code}
    public static interface MyConfig {
        public default String getTestkey() { return "default"; }
    }

   class Pojo {
        void updated(MyConfig cnf) {
                 testKey = cnf.getTestKey(); // returns "default" in case there is no configuration
         }
}

createComponent().setImplementation(Pojo.class)
    .add(createConfigurationDependency().setPid("some.pid").setCallbacks("updated", MyConfig.class).setRequired(false));
{code}

I prefer to wait for more feedback from Amdatu team before committing this.


> ConfigurationDependency should provide the setRequired() method
> ---------------------------------------------------------------
>
>                 Key: FELIX-5238
>                 URL: https://issues.apache.org/jira/browse/FELIX-5238
>             Project: Felix
>          Issue Type: Improvement
>          Components: Dependency Manager
>    Affects Versions: dependencymanager-4.3.0
>            Reporter: Guillaume Nodet
>            Assignee: Pierre De Rop
>         Attachments: FELIX-5238.patch, OptionalConfigurationDependencyTest.java
>
>
> Even though the default required for configuration is {{true}}, there's no reason why it could not be {{false}}.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)