nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Witt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NIFI-1571) Provide generic processor that would bootstrap itself from Spring's Application Context
Date Fri, 18 Mar 2016 03:02:33 GMT

    [ https://issues.apache.org/jira/browse/NIFI-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200914#comment-15200914
] 

Joseph Witt commented on NIFI-1571:
-----------------------------------

Some future thoughts:
- Would be good to document/understand the memory usage/implications.  Obviously we're floating
between worlds here and there will be some memory copy things.  We should explain those.
- Would be amazing if we can get provenance working through these flows somehow.

> 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
>
>         Attachments: request_reply_flow.xml
>
>
> 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)

Mime
View raw message