[
https://issues.apache.org/jira/browse/NIFI-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400768#comment-15400768
]
Joseph Witt commented on NIFI-2208:
-----------------------------------
[~YolandaMDavis] [~JPercivall] I recommend we consider reopening this ticket or
creating a new one. Just had a chance to look through and it appears that the
variable registry interface and implementations made their way into the
nifi-api. I don't believe the implementations should ever be in nifi-api. I
think they belong somewhere else such as nifi-framework-core. The
implementations are never a concern that would be exposed to the API users
themselves. That leaves the interface of the VariableRegistry. This too I
think does not belong here because no component should be, as I can think of
it, aware of the fact that variables are in play at all. They should certainly
never be adding/removing variables and they should only ever be consuming them.
Further, even when consuming them the substitution should occur automatically
and behind the scenes. Therefore I'd contend that at most the VariableRegistry
interface belongs in nifi-framework-api but even that i'd avoid for now. You
can tell it doesn't belong in the nifi-api because it doesn't reference any
other part of the API and no other part of the API references it.
Furthermore, I believe that the interface for VariableRegistry will need to
evolve as we'll want to support sensitive properties and not simply string
values in and out. To do so will likely require a more explicit domain model
but I agree we don't have to worry about that for now so long as we don't
expose the interface to unintended audiences and scopes.
I've gone ahead and reopened. Please advise if you disagree.
> Support Custom Properties in Expression Language - 1.x baseline
> ---------------------------------------------------------------
>
> Key: NIFI-2208
> URL: https://issues.apache.org/jira/browse/NIFI-2208
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Yolanda M. Davis
> Priority: Blocker
> Fix For: 1.0.0
>
>
> NIFI-1974 addressed this for the 0.x baseline but the PR does not apply
> cleanly to the 1.x baseline. Creating a separate JIRA for 1.x so that we can
> close out NIFI-1974 since 0.7.0 is ready to be released.
> In addition to the merge this should also include a fix to ensure that
> variable registry is initialized on startup that variables from the registry
> are applied during EL compilation based on the following order of precedence:
> 1) Flow File Attribute
> 2) Processor provided variables
> 3) User Defined Variables (via custom properties)
> 4) JVM System Properties
> 5) OS Environment Variables
> Finally the following processor properties should be enabled to support
> expression language:
> Put HDFS/Get HDFS/List HDFS
> - Directory property
> ConsumeJMS/PublishJMS
> - Destination Name property
> MS Connection Factory Provider
> -MQ ConnectionFactory Implementation (fqn classname)
> -MQ client library path
> -Broker URI
> DBCP Connection Pool:
> -Database Connection URL
> -Database Driver Class Name
> -DB Driver jar url
> -DB username
> -DB password
> ConvertCSVToAvro
> -add EL support for the following property
> -csv charset
> -and below...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
