[
https://issues.apache.org/jira/browse/NIFI-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194510#comment-15194510
]
ASF GitHub Bot commented on NIFI-1571:
--------------------------------------
Github user trkurc commented on a diff in the pull request:
https://github.com/apache/nifi/pull/271#discussion_r56102458
--- Diff: nifi-nar-bundles/pom.xml ---
@@ -54,7 +54,8 @@
<module>nifi-scripting-bundle</module>
<module>nifi-elasticsearch-bundle</module>
<module>nifi-amqp-bundle</module>
- <module>nifi-splunk-bundle</module>
+ <module>nifi-splunk-bundle</module>
--- End diff --
something strange is happening with whitespace here.
> Provide generic processor that would bootstrap itself from Spring's
> Application Context
> ---------------------------------------------------------------------------------------
>
> Key: NIFI-1571
> URL: https://issues.apache.org/jira/browse/NIFI-1571
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Oleg Zhurakousky
> Assignee: Oleg Zhurakousky
> Fix For: 0.6.0
>
>
> So, several clients have expressed interests in using WorkFlow orchestration
> frameworks such as Camel, Spring Integration etc. to be able to encapsulate
> yet modularize and externalize the complexity of some of the custom
> processors as well as handle some of the use cases that fall outside of scope
> of Data Flow paradigm (e.g., transactional context and XA between two+
> Processors).
> There is already a ticket to provide Camel support - NIFI-924. However
> realizing that both Camel and naturally Spring Integration is based on Spring
> Application Context it appears that instead of having multiple extensions we
> should have a more generic extension for a Processor that would delegate its
> processing to a bean in provided Spring Application Context (AC). This way AC
> becomes a black box and could contain anything (e.g., Camel, Spring
> Integration or some custom user code).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
