[
https://issues.apache.org/jira/browse/NIFI-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIFI-1842.
------------------------------------
Resolution: Won't Fix
With the benefit of historical background, implementing components as
generalized wrappers around a Java Domain Specific Language for processing is
not a good fit for inclusion within the Apache NiFi project.
Historical approaches included Processors for Apache Flume and the Spring
Framework, both of which were removed from NiFi 2.
Generalized frameworks are useful in themselves, but do not align well as NiFi
Processors due to multiple layers of abstraction, large numbers of
dependencies, and complexities surrounding troubleshooting. For these reasons,
Processors providing generalized integration with Apache Camel should not be
considered for inclusion in Apache NiFi itself.
> implement GetWithCamel and PutWithCamel processors, as selectable-endpoint
> connectors
> -------------------------------------------------------------------------------------
>
> Key: NIFI-1842
> URL: https://issues.apache.org/jira/browse/NIFI-1842
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: Matthew Foley
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While the SpringContextProcessor (NIFI-1571) provides an excellent basis for
> running Camel, it still requires the user to program Camel. In light of the
> fact that Camel provides some 80+ protocol-aware endpoints (see the list at
> https://github.com/apache/camel/tree/master/components), at least half of
> which are probably useful to NiFi and not yet available as NiFi-native
> processors, I propose the following:
> Create processors named GetWithCamel and PutWithCamel, that allow:
> * configuration-time selection from a subset of Camel-supported endpoints
> * and then providing the additional config values required by the selected
> endpoint, probably in an XML file
> These processors will of course be based on SpringContextProcessor, but
> hardwired for Camel and with added configuration glue in the UI to allow
> selecting a Camel endpoint without having to write Camel or Spring code. This
> won't be possible for all the endpoints, but will work for many useful ones.
> DESIGN ISSUES to be resolved (Thanks to [~joewitt],
> [[email protected]], [~ozhurakousky], for raising these items):
> * We want to add this feature without requiring that big blocks of Camel or
> Spring dependency code get sucked in to NiFi deployments that don't require
> them. Appropriate bundle isolation (at NiFi and possibly Camel levels), plus
> use of dynamic class loaders, are clearly part of the solution, but this
> strategy needs to be elaborated. The upcoming NiFi Extension Registry may
> also be part of the solution.
> * We want to avoid run-time, or even configuration-time, dependency
> resolution. While maven is a widely acknowledged utility for dependency
> resolution, it is not allowable in all environments. Resolving all
> dependencies into a metadata form at build time is preferable, and I believe
> achievable. A dependency resolver capable of downloading dependencies from
> maven repositories at config time, if not present in classpath, may still be
> useful as an option in some environments. The upcoming NiFi Extension
> Registry may also be part of the solution, if trusted in deployment
> environments.
> * The provenance-reporting feature of NiFi must be supported. How to
> integrate this with Camel end-points needs design work. It may need to be
> different for different end-points.
> * Effective code review will require patience, since Spring and Camel
> expertise may be less available in the community. Maintainability of the new
> processors must also be considered, given this limitation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
