Github user rpmiskin commented on the pull request:
https://github.com/apache/nifi/pull/180#issuecomment-177421946
@mattyb149
No worries - I seem to be quite good at misconfiguring flows to produce
errors... ;)
I spent a little time yesterday putting together a proof of concept
ReportingTask that writes provenance to ElasticSearch based on your change.
This was pretty easy but required a little refactoring to allow my
ReportingTask to share code with AbstractElasticsearchProcessor and
PutElasticSearch.
This has lead me to wonder if it would make more sense to factor out an
ElasticSearch ControllerService that could be shared between the Put/Fetch
processors and other future components, such as ReportingTasks. This is similar
to how JDBC settings are provided to ExecuteSQL via the DBCPConnectionPool. It
_might_ even allow a drop in replacement that uses the HTTP client rather than
the Transport client, although it would probably require some thought on how to
abstract out the underlying.
What do you think?
I guess if you were going to move to a ControllerService you might want to
do it before the code gets merged into master to avoid a breaking change to the
processors.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
