Re: Duplicated processors when using nifi processors dependency

[James Wing]

I created a JIRA for the nifi-aws-bundle structure,
https://issues.apache.org/jira/browse/NIFI-3950.

Is there a best practice for the abstract classes like Robert describes?
Are they a better fit for the service API bundle or the processors bundle?
Or does that become irrelevant once the NAR dependencies are aligned and
they can be references as Java libraries?

Thanks,

James

On Sun, May 21, 2017 at 10:28 AM, Bryan Bende  wrote:

> Currently the AWS NAR contains the processors, controller service API, and
> controller service implementation, all in one NAR.
>
> Typically the controller service API should be in its own NAR, so there
> should be something like:
>
> nifi-aws-bunde
> nifi-aws-service-api
> nifi-aws-service-api-nar
> nifi-aws-processors
> nifi-aws-nar
>
> The nifi-aws-service-api module would have the
> AWSCredentialsProviderService interface. The nifi-aws-nar would have a NAR
> dependency on nifi-aws-service-api-nar.
>
> Setting it up this way, you nifi-aws-utils project could have a provided
> dependency on the nifi-aws-service-api, and then your custom NAR could have
> a NAR dependency on nifi-aws-service-api-nar.
>
> There is some more information here about setting up controller services:
>
> https://cwiki.apache.org/confluence/display/NIFI/Maven+
> Projects+for+Extensions#MavenProjectsforExtensions-
> LinkingProcessorsandControllerServices  confluence/display/NIFI/Maven+Projects+for+Extensions#
> MavenProjectsforExtensions-LinkingProcessorsandControllerServices>
>
> https://github.com/bbende/nifi-dependency-example <
> https://github.com/bbende/nifi-dependency-example>
>
>
> > On May 20, 2017, at 10:06 AM, Robert  wrote:
> >
> > I tired to do move abstract aws processors from
> > nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors to newly created
> > nifi-aws-utils.
> >
> > Problem that I face now is with AWSCredentialsProviderControllerService
> that
> > imo should stay under nifi-aws-bundle, but it is required by
> > AbstractAWSCredentialsProviderProcessor that should be moved to
> > nifi-aws-utils as it is used by abstract aws processors.
> >
> > What is the preferred way to solve this?
> > Should I created new 'nifi-aws-service-bundle' under nifi-nar-bundles and
> > both nifi-aws-processors and nifi-aws-utils can depend on it?
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://apache-nifi-developer-
> list.39713.n7.nabble.com/Duplicated-processors-when-using-nifi-processors-
> dependency-tp15902p15937.html
> > Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>
>

Re: NiFi 1.2.0 Record processors question

[Koji Kawamura]

I've updated the JIRA description to cover not only embedded Avro
schema but also ones such as derived from CSVReader.
https://issues.apache.org/jira/browse/NIFI-3921

Thanks,
Koji

On Sat, May 20, 2017 at 4:14 AM, Joe Gresock  wrote:
> Yes, both of your examples help explain the use of the CSV header parsing.
>
> I think I have a much better understanding of the new framework now, thanks
> to Bryan and Matt.  Mission accomplished!
>
> On Fri, May 19, 2017 at 7:04 PM, Bryan Bende  wrote:
>
>> When a reader produces a record it attaches the schema it used to the
>> record, but we currently don't have a way for a writer to use that
>> schema when writing a record, although I think we do want to support
>> that... something like a "Use Schema in Record" option as a choice in
>> the 'Schema Access Strategy' of writers.
>>
>> For now, when a processor uses a reader and a writer, and you also
>> want to read and write with the same schema, then you would still have
>> to define the same schema for the writer to use even if you had a CSV
>> reader that inferred the schema from the headers.
>>
>> There are some processors that only use a reader, like
>> PutDabaseRecord, where using the CSV header would still be helpful.
>>
>> There are also a lot of cases where you where you would write with a
>> different schema then you read with, so using the CSV header for
>> reading is still helpful in those cases too.
>>
>> Hopefully I am making sense and not confusing things more.
>>
>>
>> On Fri, May 19, 2017 at 1:27 PM, Joe Gresock  wrote:
>> > Matt,
>> >
>> > Great response, this does help explain a lot.  Reading through your post
>> > made me realize I didn't understand the AvroSchemaRegistry.  I had been
>> > thinking it was something that nifi processors populated, but I re-read
>> its
>> > usage description and it does indeed say to use dynamic properties for
>> the
>> > schema name / value.  In that case, I can definitely see how this is not
>> > dynamic in the sense of inferring any schemas on the flow.  It makes me
>> > wonder if there would be a way to populate the schema registry from flow
>> > files.  When I first glanced at the processors, I had assumed that when
>> the
>> > schema was inferred from the CSV headers, it would create an entry in the
>> > AvroSchemaRegistry, provided you filled in the correct properties.
>> Clearly
>> > this is not how it works.
>> >
>> > Just so I understand, does your first paragraph mean that even if you use
>> > the CSV headers to determine the schema, you still can't use the *Record
>> > processors unless you manually register a matching schema in the schema
>> > registry, or otherwise somehow set the schema in an attribute?  In this
>> > case, it almost seems like inferring the schema from the CSV headers
>> serves
>> > no purpose, and I don't see how NIFI-3921 would alleviate that (it only
>> > appears to address avro flow files with embedded schema).
>> >
>> > Based on this understanding, I was able to successfully get the following
>> > flow working:
>> > InferAvroSchema -> QueryRecord.
>> >
>> > QueryRecord uses CSVReader with "Use Schema Text Property" and Schema
>> Text
>> > set to ${inferred.avro.schema} (which is populated by the InferAvroSchema
>> > processor).  It also uses JsonRecordSetWriter with a similar
>> > configuration.  I could attach a template, but I don't know the best way
>> to
>> > do that on the listserve.
>> >
>> > Joe
>> >
>> > On Fri, May 19, 2017 at 4:59 PM, Matt Burgess 
>> wrote:
>> >
>> >> Joe,
>> >>
>> >> Using the CSV Headers to determine the schema is currently the only
>> >> "dynamic" schema strategy, so it will be tricky to use with the other
>> >> Readers/Writers and associated processors (which require an explicit
>> >> schema). This should be alleviated with NIFI-3291 [1].  For this first
>> >> release, I believe the approach would be to identify the various
>> >> schemas for your incoming/outgoing data, create a Schema Registry with
>> >> all of them, then the various Record Readers/Writers using those.
>> >>
>> >> There were some issues during development related to using the
>> >> incoming vs outgoing schema for various record operations, if
>> >> QueryRecord seems to be using the output schema for querying then it
>> >> is likely a bug. However in this case it might just be that you need
>> >> an explicit schema for your Writer that matches the input schema
>> >> (which is inferred from the CSV header). The CSV Header inference
>> >> currently assumes all fields are Strings, so a nominal schema would
>> >> have the same number of fields as columns, each with type String. If
>> >> you don't know the number of columns and/or the column names are
>> >> dynamic per CSV file, I believe we have a gap here (for now).
>> >>
>> >> I thought of maybe having a InferRecordSchema processor that would
>> >> fill in the avro.text attribute for use in various 

Re: Custom processor UI exception

[Koji Kawamura]

Glad to hear you already figured it out. Thanks for your updates!

Koji

On Mon, May 22, 2017 at 10:41 AM, Yuri Krysko  wrote:
> Hi Koji,
>
> Thank you for your response. Indeed, you are right. I have sorted it out
> already :) I had a custom Abstract processor class which I was extending,
> and misused init method.
>
> Thanks again!
>
> On 5/21/17, 9:38 PM, "Koji Kawamura"  wrote:
>
>>Hello Yuri,
>>
> >From the stack trace (line numbers) I assume you are using NiFi 1.2.0.
>>If so, I think NullPointer can be thrown if your custom processor
>>returns null from its getRelationships() method. A list of possible
>>relationships from a processor should be returned, if the processor
>>doesn't have outgoing relationship, then return
>>Collections.emptySet().
>>
>>Otherwise, please let us know which version you are using.
>>
>>Thanks,
>>Koji
>>
>>On Sat, May 20, 2017 at 12:41 AM, Yuri Krysko 
>>wrote:
>>> Hello Devs,
>>>
>>> I am working on a custom processor for NiFi and I am getting the below
>>>exception in the nifi-user.log when I try to add the processor to the
>>>flow canvas. Could you please advise what could I be doing wrong. No
>>>errors in the nifi-app.log though. Thanks!
>>>
>>>
>>> 2017-05-19 11:31:07,983 ERROR [NiFi Web Server-22]
>>>o.a.nifi.web.api.config.ThrowableMapper An unexpected error has
>>>occurred: java.lang.NullPointerException. Returning Internal Server
>>>Error response.
>>>
>>> java.lang.NullPointerException: null
>>>
>>> at
>>>org.apache.nifi.web.api.dto.DtoFactory.createProcessorDto(DtoFactory.java
>>>:2226)
>>>
>>> at
>>>org.apache.nifi.web.api.dto.DtoFactory.createFlowDto(DtoFactory.java:1884
>>>)
>>>
>>> at
>>>org.apache.nifi.web.api.dto.DtoFactory.createProcessGroupFlowDto(DtoFacto
>>>ry.java:1726)
>>>
>>> at
>>>org.apache.nifi.web.StandardNiFiServiceFacade.getProcessGroupFlow(Standar
>>>dNiFiServiceFacade.java:3055)
>>>
>>> at
>>>org.apache.nifi.web.StandardNiFiServiceFacade$$FastClassBySpringCGLIB$$35
>>>8780e0.invoke()
>>>
>>> at
>>>org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
>>>
>>> at
>>>org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.inv
>>>okeJoinpoint(CglibAopProxy.java:720)
>>>
>>> at
>>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>>ectiveMethodInvocation.java:157)
>>>
>>> at
>>>org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proce
>>>ed(MethodInvocationProceedingJoinPoint.java:85)
>>>
>>> at
>>>org.apache.nifi.web.NiFiServiceFacadeLock.proceedWithReadLock(NiFiService
>>>FacadeLock.java:137)
>>>
>>> at
>>>org.apache.nifi.web.NiFiServiceFacadeLock.getLock(NiFiServiceFacadeLock.j
>>>ava:108)
>>>
>>> at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
>>>
>>> at
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>>mpl.java:43)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>> at
>>>org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodW
>>>ithGivenArgs(AbstractAspectJAdvice.java:621)
>>>
>>> at
>>>org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(
>>>AbstractAspectJAdvice.java:610)
>>>
>>> at
>>>org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundA
>>>dvice.java:68)
>>>
>>> at
>>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>>ectiveMethodInvocation.java:179)
>>>
>>> at
>>>org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(Ex
>>>poseInvocationInterceptor.java:92)
>>>
>>> at
>>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>>ectiveMethodInvocation.java:179)
>>>
>>> at
>>>org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor
>>>.intercept(CglibAopProxy.java:655)
>>>
>>> at
>>>org.apache.nifi.web.StandardNiFiServiceFacade$$EnhancerBySpringCGLIB$$c6b
>>>bb5bc.getProcessGroupFlow()
>>>
>>> at org.apache.nifi.web.api.FlowResource.getFlow(FlowResource.java:375)
>>>
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>> at
>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>>:62)
>>>
>>> at
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>>mpl.java:43)
>>>
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>> at
>>>com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethod
>>>InvokerFactory.java:60)
>>>
>>> at
>>>com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDi
>>>spatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatc
>>>hProvider.java:205)
>>>
>>> at
>>>com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispat
>>>cher.dispatch(ResourceJavaMethodDispatcher.java:75)
>>>
>>> at
>>>com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule
>>>.java:302)
>>>
>>> at

Re: Custom processor UI exception

[Yuri Krysko]

Hi Koji,

Thank you for your response. Indeed, you are right. I have sorted it out
already :) I had a custom Abstract processor class which I was extending,
and misused init method.

Thanks again!

On 5/21/17, 9:38 PM, "Koji Kawamura"  wrote:

>Hello Yuri,
>
>From the stack trace (line numbers) I assume you are using NiFi 1.2.0.
>If so, I think NullPointer can be thrown if your custom processor
>returns null from its getRelationships() method. A list of possible
>relationships from a processor should be returned, if the processor
>doesn't have outgoing relationship, then return
>Collections.emptySet().
>
>Otherwise, please let us know which version you are using.
>
>Thanks,
>Koji
>
>On Sat, May 20, 2017 at 12:41 AM, Yuri Krysko 
>wrote:
>> Hello Devs,
>>
>> I am working on a custom processor for NiFi and I am getting the below
>>exception in the nifi-user.log when I try to add the processor to the
>>flow canvas. Could you please advise what could I be doing wrong. No
>>errors in the nifi-app.log though. Thanks!
>>
>>
>> 2017-05-19 11:31:07,983 ERROR [NiFi Web Server-22]
>>o.a.nifi.web.api.config.ThrowableMapper An unexpected error has
>>occurred: java.lang.NullPointerException. Returning Internal Server
>>Error response.
>>
>> java.lang.NullPointerException: null
>>
>> at
>>org.apache.nifi.web.api.dto.DtoFactory.createProcessorDto(DtoFactory.java
>>:2226)
>>
>> at
>>org.apache.nifi.web.api.dto.DtoFactory.createFlowDto(DtoFactory.java:1884
>>)
>>
>> at
>>org.apache.nifi.web.api.dto.DtoFactory.createProcessGroupFlowDto(DtoFacto
>>ry.java:1726)
>>
>> at
>>org.apache.nifi.web.StandardNiFiServiceFacade.getProcessGroupFlow(Standar
>>dNiFiServiceFacade.java:3055)
>>
>> at
>>org.apache.nifi.web.StandardNiFiServiceFacade$$FastClassBySpringCGLIB$$35
>>8780e0.invoke()
>>
>> at
>>org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
>>
>> at
>>org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.inv
>>okeJoinpoint(CglibAopProxy.java:720)
>>
>> at
>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>ectiveMethodInvocation.java:157)
>>
>> at
>>org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proce
>>ed(MethodInvocationProceedingJoinPoint.java:85)
>>
>> at
>>org.apache.nifi.web.NiFiServiceFacadeLock.proceedWithReadLock(NiFiService
>>FacadeLock.java:137)
>>
>> at
>>org.apache.nifi.web.NiFiServiceFacadeLock.getLock(NiFiServiceFacadeLock.j
>>ava:108)
>>
>> at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
>>
>> at
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:498)
>>
>> at
>>org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodW
>>ithGivenArgs(AbstractAspectJAdvice.java:621)
>>
>> at
>>org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(
>>AbstractAspectJAdvice.java:610)
>>
>> at
>>org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundA
>>dvice.java:68)
>>
>> at
>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>ectiveMethodInvocation.java:179)
>>
>> at
>>org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(Ex
>>poseInvocationInterceptor.java:92)
>>
>> at
>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl
>>ectiveMethodInvocation.java:179)
>>
>> at
>>org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor
>>.intercept(CglibAopProxy.java:655)
>>
>> at
>>org.apache.nifi.web.StandardNiFiServiceFacade$$EnhancerBySpringCGLIB$$c6b
>>bb5bc.getProcessGroupFlow()
>>
>> at org.apache.nifi.web.api.FlowResource.getFlow(FlowResource.java:375)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>:62)
>>
>> at
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:498)
>>
>> at
>>com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethod
>>InvokerFactory.java:60)
>>
>> at
>>com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDi
>>spatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatc
>>hProvider.java:205)
>>
>> at
>>com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispat
>>cher.dispatch(ResourceJavaMethodDispatcher.java:75)
>>
>> at
>>com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule
>>.java:302)
>>
>> at
>>com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPa
>>thRule.java:147)
>>
>> at
>>com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceCla
>>ssRule.java:108)
>>
>> at
>>com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPa
>>thRule.java:147)
>>
>> at

Re: Custom processor UI exception

[Koji Kawamura]

Hello Yuri,

>From the stack trace (line numbers) I assume you are using NiFi 1.2.0.
If so, I think NullPointer can be thrown if your custom processor
returns null from its getRelationships() method. A list of possible
relationships from a processor should be returned, if the processor
doesn't have outgoing relationship, then return
Collections.emptySet().

Otherwise, please let us know which version you are using.

Thanks,
Koji

On Sat, May 20, 2017 at 12:41 AM, Yuri Krysko  wrote:
> Hello Devs,
>
> I am working on a custom processor for NiFi and I am getting the below 
> exception in the nifi-user.log when I try to add the processor to the flow 
> canvas. Could you please advise what could I be doing wrong. No errors in the 
> nifi-app.log though. Thanks!
>
>
> 2017-05-19 11:31:07,983 ERROR [NiFi Web Server-22] 
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred: 
> java.lang.NullPointerException. Returning Internal Server Error response.
>
> java.lang.NullPointerException: null
>
> at 
> org.apache.nifi.web.api.dto.DtoFactory.createProcessorDto(DtoFactory.java:2226)
>
> at org.apache.nifi.web.api.dto.DtoFactory.createFlowDto(DtoFactory.java:1884)
>
> at 
> org.apache.nifi.web.api.dto.DtoFactory.createProcessGroupFlowDto(DtoFactory.java:1726)
>
> at 
> org.apache.nifi.web.StandardNiFiServiceFacade.getProcessGroupFlow(StandardNiFiServiceFacade.java:3055)
>
> at 
> org.apache.nifi.web.StandardNiFiServiceFacade$$FastClassBySpringCGLIB$$358780e0.invoke()
>
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
>
> at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
>
> at 
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:85)
>
> at 
> org.apache.nifi.web.NiFiServiceFacadeLock.proceedWithReadLock(NiFiServiceFacadeLock.java:137)
>
> at 
> org.apache.nifi.web.NiFiServiceFacadeLock.getLock(NiFiServiceFacadeLock.java:108)
>
> at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at 
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
>
> at 
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
>
> at 
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:68)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
>
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>
> at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
>
> at 
> org.apache.nifi.web.StandardNiFiServiceFacade$$EnhancerBySpringCGLIB$$c6bbb5bc.getProcessGroupFlow()
>
> at org.apache.nifi.web.api.FlowResource.getFlow(FlowResource.java:375)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at 
> com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
>
> at 
> com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
>
> at 
> com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
>
> at 
> com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
>
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>
> at 
> com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
>
> at 
> com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
>
> at 
> com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
>
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
>
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
>
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>
> at 
> 

Re: Duplicated processors when using nifi processors dependency

[Bryan Bende]

Currently the AWS NAR contains the processors, controller service API, and 
controller service implementation, all in one NAR.

Typically the controller service API should be in its own NAR, so there should 
be something like:

nifi-aws-bunde
nifi-aws-service-api
nifi-aws-service-api-nar
nifi-aws-processors
nifi-aws-nar

The nifi-aws-service-api module would have the AWSCredentialsProviderService 
interface. The nifi-aws-nar would have a NAR dependency on 
nifi-aws-service-api-nar.

Setting it up this way, you nifi-aws-utils project could have a provided 
dependency on the nifi-aws-service-api, and then your custom NAR could have a 
NAR dependency on nifi-aws-service-api-nar.

There is some more information here about setting up controller services:

https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Extensions#MavenProjectsforExtensions-LinkingProcessorsandControllerServices
 


https://github.com/bbende/nifi-dependency-example 



> On May 20, 2017, at 10:06 AM, Robert  wrote:
> 
> I tired to do move abstract aws processors from
> nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors to newly created
> nifi-aws-utils.
> 
> Problem that I face now is with AWSCredentialsProviderControllerService that
> imo should stay under nifi-aws-bundle, but it is required by
> AbstractAWSCredentialsProviderProcessor that should be moved to
> nifi-aws-utils as it is used by abstract aws processors.
> 
> What is the preferred way to solve this?
> Should I created new 'nifi-aws-service-bundle' under nifi-nar-bundles and
> both nifi-aws-processors and nifi-aws-utils can depend on it?
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/Duplicated-processors-when-using-nifi-processors-dependency-tp15902p15937.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.