Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
Date: Wed, 7 Jun 2017 12:44:18 +0000 (UTC)
From: "Aled Sage (JIRA)" <jira@apache.org>
To: dev@brooklyn.apache.org
Message-ID: <JIRA.13077954.1496831021000.17985.1496839458491@Atlassian.JIRA>
In-Reply-To: <JIRA.13077954.1496831021000@Atlassian.JIRA>
References: <JIRA.13077954.1496831021000@Atlassian.JIRA> <JIRA.13077954.1496831021708@jira-lw-us.apache.org>
Subject: [jira] [Commented] (BROOKLYN-514) Delay resolution of http request
 sensor settings
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 07 Jun 2017 12:44:24 -0000


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

Aled Sage commented on BROOKLYN-514:
------------------------------------

I discussed with [~Nakomis] how we'd implement this. We believe it would require the steps described below:

* Change {{org.apache.brooklyn.core.sensor.http.HttpRequestSensor.apply(Entity)}} so that it doesn't immediately call {{EntityInitializers.resolve}} for the headers, credentials, etc. Instead use a {{Supplier}}, similar to how it's done for {{uri}}.
* Change {{HttpFeed}} to overload the builder methods so they also take the supplier, and passes it through to {{HttpPollIdentifier}}
* Change the Callable job (created in {{HttpFeed.preStart}} so that it calls {{headersProvider.get()}} etc each time.
* Preserve backwards-compatibility of persisted state, which will include {{HttpPollIdentifier}} instances:
  * add fields like {{headersProvider}}, while also keeping {{headers}} field (appropriately documented to say why we're keeping them).
  * implement something like {{HttpPollIdentifier.readResolve()}} to populate the {{headersProvider}} from the {{headers}} field, and set the old {{headers}} field to null.
* Write a backwards-compatibility test, similar to {{org.apache.brooklyn.core.mgmt.rebind.RebindHistoricSshFeedTest}}
  * Create persisted state (before making this fix), and capture the persistence file for the {{HttpFeed}} and the entity (with headers etc being explicitly configured).
  * Write the test that injects those files, rebinds, and then confirms that the HttpFeed is functional (similar to {{org.apache.brooklyn.feed.http.HttpFeedTest}}).
* Add to our {{HttpRequestSensorYamlTest}}, to show that we can use deferred-suppliers for uri, headers, username and password, and to prove that the values are resolved on each poll (e.g. by using an external config supplier in the test so we can change the value on-the-fly)


> Delay resolution of http request sensor settings
> ------------------------------------------------
>
>                 Key: BROOKLYN-514
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-514
>             Project: Brooklyn
>          Issue Type: Improvement
>            Reporter: Martin Harris
>            Priority: Minor
>
> Currently, the username, password, and headers of a HttpRequestSensor are resolved when the sensor is created [1]. This causes two problems: 1. dependent values cannot be used, e.g. the headers may need to contain a security token which is not obtained until later, and 2. sensitive values such as password will be persisted
> [1]: https://github.com/apache/brooklyn-server/blob/30292c967b3368b2b58d2b00de965ab32ea456d6/core/src/main/java/org/apache/brooklyn/core/sensor/http/HttpRequestSensor.java#L85-L87


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)