[
https://issues.apache.org/jira/browse/MINIFI-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408309#comment-16408309
]
ASF GitHub Bot commented on MINIFI-424:
---------------------------------------
Github user apiri commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/117#discussion_r176170883
--- Diff:
minifi-commons/minifi-commons-schema/src/test/java/org/apache/nifi/minifi/commons/schema/serialization/SchemaLoaderTest.java
---
@@ -84,13 +85,92 @@ public void testUnsupportedVersion() throws
IOException, SchemaLoaderException {
}
}
+ @Test
+ public void testMinimalConfigV3VersionUnusedProperties() throws
IOException, SchemaLoaderException {
+ Properties inputProperties = new Properties();
--- End diff --
Minor, but could we also have these tests drawing from a sample
bootstrap.conf in lieu of just seeding the properties. With some of the work
that is underway surrounding C2 would not want to miss coverage of this
functionality.
> Expose bootstrap properties in the ConfigTransformer
> ----------------------------------------------------
>
> Key: MINIFI-424
> URL: https://issues.apache.org/jira/browse/MINIFI-424
> Project: Apache NiFi MiNiFi
> Issue Type: New Feature
> Reporter: Joseph Percivall
> Assignee: Joseph Percivall
> Priority: Major
>
> The ConfigTransformer takes in the config.yml and creates the nifi.properties
> and flow.xml. In order to better support customizations on a per MiNiFi
> instance for things that aren't able to reference EL, we could expose the
> properties listed in the bootstrap.conf.
> As an example, the bootstrap conf could have properties identifying the S2S
> URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it
> would translate the keys to their proper values as identified in the
> bootstrap.conf.
> The main unknown is what the "escape" identifiers would be. In EL it is "${
> ..... }" (not sure why Jira is formatting this with new lines). This would
> need to be specific enough that it doesn't collide with anything that'd be in
> the config.yml.
> Much further down the line, this could eventually evolve to expose ENV
> variables, key/values stored in a file, and maybe even basic functions as
> needed. Essentially a basic version of EL but I hesitate to call it that b/c
> I don't want users to expect all of that functionality. This should really be
> for things that can't be done via EL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
