I've updated the migration guidance to better highlight this change:
https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance
It is important to note that GetFile has never been driven by input
flow files. The desire for that totally makes sense and that is what
the ListFile/FetchFile
To toss in another instance where this change can act against valid
use-cases, consider any instance where you might want to use the Expression
Language to cause one of these 'source' processors to not only run on a
'trigger', but also run more dynamically. Previously, you could potentially
use Ext
Aha, that makes sense. Thanks for the explanation! I do agree that it could
be useful to have control over when those types of processors execute.
We should update the migration guide to describe this scenario.
I can do it in just a bit if nobody else has.
On Dec 22, 2015 11:51 AM, "Aldrin Piri" wrote:
> Ricky,
>
> This was only applied to processors where they, for lack of other words,
> had explicit requirements of input; either requirin
Ricky,
This was only applied to processors where they, for lack of other words,
had explicit requirements of input; either requiring or ignoring. GetFile
is one such example and the framework previously allowed users to connect
processors to anything regardless of whether or not they actually con
I noticed that in NiFi 0.4.0, a few processors (i.e. GetFile) are annotated
with @InputRequirement(Requirement.INPUT_FORBIDDEN), which is a little
confusing to me. What is the reasoning for forbidding an input connection
to processors like GetFile? There are situations where you want the ability
to
