[jira] [Commented] (MINIFI-408) Improve handling of bundle versioning in NARs with other NARs as dependencies

["Aldrin Piri (JIRA)" <ji...@apache.org>]

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

Aldrin Piri commented on MINIFI-408:
------------------------------------

Was able to resolve the startup issues and, as part of the component lookup, resolve the issues of MINIFI-348.  This ultimately was a product of moving the transform process to the runtime portion of the project instead of the bootstrap where all the classpaths were established in the context of the application; something that was not possible with the bootstrap.  

Currently I am looking at establishing how to manage the change notifiers that occur.  These have a lot of failover and fall back in the case of bad config.  Unfortunately, with the transform process in the runtime of minifi, there is no quick means of fail fast to relay information about a bad config.  My current thought process is to perform the base transform as was originally done and then extract the "enrichment" of bundle information out from the transform process.

This would mean that a new config, whether through startup or one of the change ingestors, would have the initial flow.xml.gz creation performed in bootstrap.  If all that was correct, the process would carry on as before but before launching the minifi process and handing off to the nifi-framework internals, we would perform the enrichment against the xml in lieu of the yaml.  This is redundant in terms of IO but the least invasive short of modifying nifi internals at this juncture. 

> Improve handling of bundle versioning in NARs with other NARs as dependencies
> -----------------------------------------------------------------------------
>
>                 Key: MINIFI-408
>                 URL: https://issues.apache.org/jira/browse/MINIFI-408
>             Project: Apache NiFi MiNiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 0.2.0
>            Reporter: Aldrin Piri
>            Assignee: Aldrin Piri
>            Priority: Blocker
>
> Parts of this have cropped up in a few tickets affecting CNFEs and inability to load processors.  This is typically exacerbated by the inclusion of NiFi processors which also depend on NiFi Standard Services API NAR (typically for SSL Context Service).  This can lead to problems when MiNiFi is started as the transformed flow is effectively a <1.2 version which does not have the bundling information established.  Accordingly, in the case above where I bring a separate processor NAR with its associated versioned, services NAR, there are two instances which leads to a ghost implementation.  For NiFI, this is resolved in the UI to select the desired version but we have no such facility in MiNiFi.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)