NIFI-210: Add ExecuteScript and InvokeScriptedProcessor

[mattyb149]

No description provided.

[rickysaltzer]

This processor should be annotated with @InputRequirement(Requirement.INPUT_REQUIRED) since it can't be executed without an input FlowFile.

[joewitt]

since we're giving the script access to the session and since we cannot possible know its intent I say we stop pulling a flowfile for them and let them do it. In so doing we can remove the input required need as well and let scripts be used as ways to source data as well. Basically "Here script - we've given you a process session - have fun but you're responsible for accounting for the flow files transfers"

[rickysaltzer]

absolutely agree with @joewitt. Removing the requirement for input opens up a lot more use cases.

[markap14]

@mattyb149 wow this set of Processors is quite a feat! :) I provided feedback in the way of several inline comments. The only other thing that I would recommend is to consider factoring out a parent Abstract class or a util class. It seems like both Processors have quite a lot of overlap that could be simplified with either one of those approaches. Very cool to get these Processors in though! THanks for all of the work that you've put into getting this done!

[mattyb149]

TL;DR Will take a fresh look at this :)

I wanted very badly to have a parent Abstract base class, but the two processors extend from different parent classes (AbstractProcessor and AbstractSessionFactoryProcessor). Now that the behavior of ExecuteScript has changed to let the script handle the session and transfers, perhaps I can refactor that, at which point I will certainly pull the common code out. I thought about a Util class too but the methods looked like they'd need large signatures to get all the dependencies injected.

[markap14]

You added a comment indicating that custom validation will ensure that exactly 1 of the Script File or Script Body is populated but the implementation just delegates to the super class, which returns an empty collection, I believe..

[joewitt]

seems like something a bit wonky is happening here. So if one enters a valid script then enters a buggy script the original value is set and not being replaced. Then because if there is an invalid script and no modulepath the error is being buried. Definitely need the old script/processor that was compiled to get wiped out and we need the errors to always make it to the log/bulletin.