Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
InvokeHTTP is a very useful processor as it is, but there are many scenarios, where a modified/extended version of its basic functionality is a much better match to the problem at hand. Especially when creating complex flows to achieve such extensions is not an option.
The final keyword was removed from the implementing class some time ago, but because of the way how its code is structured, with many private methods and rather "monolithic" structure of its onTrigger method, this alone is not sufficient to allow for easy extensibility via derivation.
The only way how such extensions can be realized at present is to copy huge parts of the original code and tweak it in a specialized instance of a new processor. Which can lead to a whole set of new problems, such as copied code not matching the code style and/or quality requirements (cyclomatic complexity being one typical example) of the "host" code base.
Restructuring parts of the code would go a long way in enabling such scenarios in a much easier and cleaner way. This would include making several key methods protected instead of private and also splitting the bigger methods into logically more coherent and also more manageable (and overridable) chunks.
Attachments
Issue Links
- duplicates
-
NIFI-7482 InvokeHTTP should not be final
- Resolved
- is related to
-
NIFI-10244 Add WebClientService Abstraction for HTTP Operations
- Resolved
-
NIFI-9015 Ability to derive custom Rest API processes from InvokeHTTP
- Closed