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

ASF GitHub Bot commented on NIFI-1571:
--------------------------------------

Github user trkurc commented on the pull request:

    https://github.com/apache/nifi/pull/271#issuecomment-197617908
  
    @olegz : checkstyle fails when I build with your latest commit
    ``
    [INFO] --- maven-checkstyle-plugin:2.15:check (check-style) @ 
nifi-spring-processors ---
    [WARNING] 
src/main/java/org/apache/nifi/spring/SpringContextFactory.java[44] (regexp) 
RegexpSinglelineJava: Line has trailing whitespace.
    [WARNING] 
src/main/java/org/apache/nifi/spring/SpringContextFactory.java[51] (regexp) 
RegexpSinglelineJava: Line has trailing whitespace.
    [WARNING] 
src/main/java/org/apache/nifi/spring/SpringContextFactory.java[61] (regexp) 
RegexpSinglelineJava: Line has trailing whitespace.
    [WARNING] 
src/test/java/org/apache/nifi/spring/SpringContextFactoryTests.java[20:15] 
(imports) UnusedImports: Unused import - org.junit.Assert.assertFalse.
    ``


> 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)

Reply via email to