[
https://issues.apache.org/jira/browse/NIFI-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194520#comment-15194520
]
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_r56103351
--- 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>
+ </ul>
+ The example below demonstrates template configuration for
bi-directional Spring Application Context configuration:
+ <code>
+ <pre>
+ <int:channel id=”fromNiFi”/>
+
+ <!—
+ your custom app configuration to receive messages from ‘fromNiFi’
channel and optionally send back to NiFi via ‘toNiFi’ channel.
+ It could contain any Spring-based application (i.e., Spring
Integration, Apache Camel and/or custom code). All you need to do is inject
+ channels into your beans and send/receive messages from it.
+ -->
+
+ <int:channel id="toNiFi">
+ <int:queue/>
+ </int:channel>
+ </pre>
+ </code>
+ </p>
+ <p>
+ The component is based on assumption that user has an existing
Spring Application encapsulated in Spring Context that exposes optional in/out
+ MessagingChannels to allow data to flow to/from ApplicationContext
and into/out-of. NiFi.
+ Such application is realized by having a directory on the file
system, which contains contains all required resources for such application to
run.
+ Such resources usually are JAR files to satisfy application's
class-path as well as JAR representing the application and its configuration.
+ Below is the example of what such directory may contain. In this
case the 'SI_DEMO-0.0.1-SNAPSHOT.jar' represents the actual application and the
rest
+ of the JARs represent class-path dependency required by an
application.
+ <pre>
+ deps
+ ├── SI_DEMO-0.0.1-SNAPSHOT.jar
+ ├── aopalliance-1.0.jar
+ ├── commons-logging-1.2.jar
+ ├── spring-aop-4.2.4.RELEASE.jar
+ ├── spring-beans-4.2.4.RELEASE.jar
+ ├── spring-context-4.2.4.RELEASE.jar
+ ├── spring-core-4.2.4.RELEASE.jar
+ ├── spring-expression-4.2.4.RELEASE.jar
+ ├── spring-integration-core-4.2.5.RELEASE.jar
+ ├── spring-messaging-4.2.4.RELEASE.jar
+ </pre>
+ </p>
+ <p>
+ You introduce the processor the usual way and then configure its
properties:
+ <ul>
+ <li><i><b>Application Context config path</b></i> [REQUIRED] - a
path to the Application Context configuration.
+ The path is relative to the class-path of the application defined
by the <i>Application Context class path</i> property </li>
+ <li><i><b>Application Context class path</b></i> [REQUIRED] - a
path to a directory on the file system where application dependencies are. </li>
+ <li><i>Send Timeout</i> [OPTIONAL] - the wait time for sending
messages to Spring Application Context. Only required if NiFi plans to send
data o Spring.
--- End diff --
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)
