THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
| Page properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Goals
Run multiple versions of the same processor, controller service, or reporting task in the same NiFi instance
Background and strategic fit
...
In order to eventually support an extension registry, it will become important to know the version of a component and to support running different versions of the same component at the same time.
NAR Maven Plugin
The NAR Maven Plugin currently produces a MANIFEST file with the following content, using the nifi-hadoop-nar as an example:
...
The combination of the Nar-Group-Id, Nar-Id, and Nar-Version will be considered the component coordinates for an instance of a component created from the given NAR.
Class Loading
NarClassLoaders identifies all the NARs in the lib directory and creates a map from Nar-Id to a ClassLoader for the given NAR. It is also responsible for creating the link between a NAR’s ClassLoader and the dependent NAR’s ClassLoader, if one exists.
...
If NiFi detects multiple NARs with the same exact Nar-Group-Id, Nar-Id, and Nar-Version, then start-up will fail.
Creating Components
When creating components the user will be able to see the component coordinates for each processor name. For example, if two version of the nifi-hadoop-bundle were deployed to the lib directory, the user would be able to choose between different versions of the PutHdfs processor:
...
This will require updating REST endpoints and DTOs to pass along additional information.
Serialization
The component coordinates will be captured in the serialized representation of the flow.xml, templates, and versioned flows. For example, if we had a PutHdfs processor from nifi-hadoop-nar 1.0.0 and a PutHdfs processor from nifi-hadoop-nar 1.1.0, the flow.xml would show something like the following:
...