[jira] [Commented] (MINIFI-253) Make Processors pluggable

["marco polo (JIRA)" <ji...@apache.org>]

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

marco polo commented on MINIFI-253:
-----------------------------------

[~aldrin] [~bryanrosander@gmail.com] https://github.com/phrocker/nifi-minifi-cpp/commit/0d3388d0136c51abb97a12cde22ed94cf3688e8e is a commit to begin the discussion:

I believe MINIFI-253 is tantamount to the JAVA classloader. It functions as the capability that drives load and reloading of classes. I think it's reasonable to envision C2 as being the driver. Architecturally, C2 would be the enforcer of reloads, whether it is a simple trigger or more in terms of full control of what is run/restarted. Currently we lack the foundation to support the basic process of loading, reloading, or unloading. MINIFI-253 is a small step toward this goal and does not obviate any work in MINIFI-64 or for the implementing an extension registry. In reality it is a supplement to these discussions.

With that said, knowing that C2 may architecturally control this, the commit I've provided includes a basic "Default Class Loader." This functions as the system class loader, but requires processors to REGISTER themselves. This isn't very different from the large if/else statement we had previously. When any type of change is requested by C2 we would simply create child class loader(s) with self registering objects and instantiate them in the same way. In a larger discussion we could discuss capabilities, but the goal of MINIFI-253 is mean to allow operations such as eventual unloading and reloading of objects that were replaced by C2 due to rolling upgrades, for example. There is still more to be discussed and implemented, but knowing that we can eventually replace several components would be useful. 

One utility of the work here is knowing that we may have devices in the wild with very little bandwidth. If we could ship a small shared object with replacement code we could potentially resolve bugs or implement functionality without a difficult rollout. Again...still a lot needs to be done to facilitate an "extension registry" but we might want to take a step back and consider the need that this "extension registry" also functions as a "core component registry" whereby we can replace core functionality if a defect arises. Pulling this functionality back to all levels might facilitate this. 



> Make Processors pluggable 
> --------------------------
>
>                 Key: MINIFI-253
>                 URL: https://issues.apache.org/jira/browse/MINIFI-253
>             Project: Apache NiFi MiNiFi
>          Issue Type: Improvement
>          Components: C++
>            Reporter: marco polo
>
> Processors are currently Hardcoded and created within a large if statement within FlowController. Once processors are contributed and can be removed, we need to have the ability to a pluggable way to inject processors, be it from a shared object, configuration file, or compiled in. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)