[
https://issues.apache.org/jira/browse/NIFIREG-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605735#comment-16605735
]
Bryan Bende commented on NIFIREG-139:
-------------------------------------
Since controller services are extensions we can't really ensure that all
controller services would have the new property, or that they would support
dyanmic properties, because anyone can implement their own CS that doesn't
provide those. For the "Mapping Name" idea it could be built into all
controller services at the framework level, but I'm not sure that I like the
idea of modifying core NiFi to support this concept, since the primary use case
is someone using the UI where this is not an issue. It is only an issue when
trying to script deployments which core NiFi has no concept of whether that is
being done or not, so it feels more appropriate for the CLI to handle this in
some way.
> Nifi registry should pick up the controller service definitions while
> deploying a flow
> --------------------------------------------------------------------------------------
>
> Key: NIFIREG-139
> URL: https://issues.apache.org/jira/browse/NIFIREG-139
> Project: NiFi Registry
> Issue Type: Bug
> Affects Versions: 0.1.0
> Reporter: ohad israeli
> Priority: Critical
>
> I am trying to use the registry to copy a simple flow for example of
> httprequest->joltconversion->httpresponse.
> This flow is using the internal http context service which is installed and
> configured on the source (dev env). While deploying the flow to the target
> (prod env) the flow cant find the service on the target (prod end)
> to summarize, on deployment of a flow if the flow is using a service
> controller its setting should also be deployed on the target machine
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
