[
https://issues.apache.org/jira/browse/NIFI-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17940962#comment-17940962
]
Luigi Baldari commented on NIFI-1842:
-------------------------------------
Hello,
I have added a pull request to GitHub
(https://github.com/apache/nifi/pull/9847) which provides integration of Apache
Nifi with Apache Camel. However, the proposed approach is different from the
one described in this issue: there is no Get / Put processors but instead there
is a single ExecuteCamelRoute processor which allows the user to specify the
Camel route with a DSL (Xml or Yaml). The main idea here is that Get/Put
processors are still handled by nifi and ExecuteCamelRoute can be used to
perform transformations using the Apache Camel framework.
Two camel endpoints are generated by default: *direct:in* (where the input flow
files are sent) and *direct:err* (where the error flow files are sent). Then
one or more output relationships are created dynamically depending from the
user input.
The approach does not use Spring. A set of camel components are loaded from the
pom and can be used to define the route:
* [https://camel.apache.org/components/4.8.x/bean-component.html]
* [https://camel.apache.org/components/4.8.x/netty-http-component.html]
* [https://camel.apache.org/components/4.8.x/languages/groovy-language.html]
* [https://camel.apache.org/components/4.8.x/languages/jsonpath-language.html]
*
[https://camel.apache.org/components/4.8.x/dataformats/jackson-dataformat.html]
More strategic camel components can be added or we can decide to go with a more
dynamic apporach.
Any feedback is appreaciated.
Thanks
Luigi
> 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: 10m
> 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)
