[ https://issues.apache.org/jira/browse/NIFI-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Puspendu Banerjee updated NIFI-1842: ------------------------------------ Comment: was deleted (was: [~mattf] in-case you want to join the discussion on registry : https://cwiki.apache.org/confluence/display/NIFI/Extension+Registry) > 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: Matt Foley > Assignee: Matt Foley > > 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], > [~puspendu.baner...@gmail.com], [~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 (v6.3.4#6332)