[
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)
