[
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] [[email protected]]
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)
