[
https://issues.apache.org/jira/browse/NIFI-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194558#comment-15194558
]
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_r56105879
--- Diff:
nifi-nar-bundles/nifi-spring-bundle/nifi-spring-processors/src/main/resources/docs/org.apache.nifi.spring.SpringContextProcessor/additionalDetails.html
---
@@ -0,0 +1,94 @@
+<!DOCTYPE html>
+<html lang="en">
+ <!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version
2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+ http://www.apache.org/licenses/LICENSE-2.0
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+ <head>
+ <meta charset="utf-8" />
+ <title>SpringContextProcessor</title>
+ <link rel="stylesheet" href="../../css/component-usage.css"
type="text/css" />
+ </head>
+
+ <body>
+ <!-- Processor Documentation
================================================== -->
+ <h2>Description:</h2>
+ <p>
+ <b>SpringContextProcessor</b> – allows integration of
processes encapsulated in Spring Application Context to run as NiFi
+ processor by becoming a runtime host for an instance of Spring
Application Context.
+ </p>
+ <p>
+ Communication between NiFi and process encapsulated within
Spring Application Context is accomplished via Spring Messaging
+ (one of the core modules of Spring Framework) and supports 3
usage modes:
+ <ul>
+ <li><i>Headless</i> - no interaction with NiFi, meaning
nothing is sent to it and nothing is received from it (i.e., some monitoring
app).
+ In this case NiFi simply plays the role of the runtime
host.</li>
+ <li><i>One way (NiFi -> Spring or Spring ->
NiFi). </i> - This depends on existence of pre-defined message channel in
Spring
+ Application Context. The name of the channel should be
“fromNiFi” and the type
<i>org.springframework.messaging.MessageChannel.</i></li>
+ <li><i>By-directional (NiFi -> Spring -> Nifi or
Spring -> NiFi -> Spring)</i> - This depends on existence of two channels
+ in Spring Application Context. One channel receives
messages from NiFi with name “fromNiFi” and type
<i>org.springframework.messaging.MessageChannel</i>i>
+ and another is o receive messages from Spring with
name “toNiFi” and type
<i>org.springframework.messaging.PollableChannel.</i></li>
--- End diff --
another typo: s/ o / to / ?
> 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)
