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 depen
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 hea
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 mi
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 a
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
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-ap
