Howdy,
I have created my own processor which I have been testing with
NiFi for a while now. This stuff used to work for me, now it doesn't. Today
nifi won't start. The nifi-app.log is below
The processor reads in an image type NITF and does a few things with it. I do
a:
$ mvn
Ok so in seeing this part of the stackdump we know there is a
'classpath thing' going on
"Caused by: java.lang.ClassNotFoundException: org.mitre.nifi.NiFiNITFReader"
And we see from your provided info that your jar does contain such a class
"22243 Wed Oct 21 10:36:46 EDT 2015 org/mitre/nifi
I noticed similar error when I have my flow using older version of a custom
nar and when I deployed new version of nar with package refactoring.
My workaround to bring the server back is to redeploy old nar, start nifi
and delete the flow then recreate the flow after deploying refactored nar.
Nifi
Sumanth,
Do you happen to still have the stack traces around? Unless we do
some breaking/API unfriendly thing such issues should simply not
occur. Want to make sure we understand what is happening here.
Thanks
Joe
On Wed, Oct 21, 2015 at 8:56 PM, Sumanth Chinthagunta wrote:
> I noticed simila
My case is simple and easy to reproduce:
1. Create a flow with custom processor (e.g. abc.MyProcesser )
2. Make sure flow is working. Then stop the server.
3. Replace nar in lib with new nar after refactoring processor's package (
e.g., xzy.MyProcesser)
4. When you try to start nifi , it fails w
Ahhh - no need to send the logs now. Totally understand. We need to
do something for your case for sure. We should startup and just have
some sort of ghost/placeholder processor in the flow and prompt the
user to select a new one.
https://issues.apache.org/jira/browse/NIFI-1052
On Wed, Oct 21,
We should also check similar behavior for missing properties. I was
thinking about this today while modifying a custom processor and decided it
was safest to just make a new processor with the new properties.
I tried to find info in the developer guide but couldn't. It would be good
to document wh
Alan
That is a great point. We talk about this a little bit in our version
guide [1]. But I agree with you that we should make this a fully
documented concept in the developer guide (so they know what they
can/cannot do) and possibly the user guide (so they know what was done
to them). We need
