Steven, Joe and Bryan's suggestions are best, but there is another way to try to resolve your issue, It comes with a large "Beware of class loaders" sign, but it can work.
Your custom nar can be built so that it depends on the classes found in nifi-standard-nar, by using a nar dependency. A nar dependency essentially tells NiFi that your custom nar's class loader should use the nar dependency's class loader as its parent To setup a nar dependency, you would add the below snippet to the pom.xml that builds your custom nar. <dependency> <groupId>org.apache.nifi</groupId> <artifactId>nifi-standard-nar</artifactId> <version>1.4.0</version> <type>nar</type> </dependency> The <type>nar</type> is very important and is recognized by the nifi-nar-maven-plugin. Then you must mark the jars that exist inside the nifi-standard-nar as <scope>provided</scope> so that they do not also get copied into your custom nar. When code in your custom nar needs the inherited code, your nar's class loader will load the inherited classes using its parent class loader. Regards, -- Mike On Tue, Dec 26, 2017 at 2:04 PM, Joe Witt <joe.w...@gmail.com> wrote: > Steven > > Understood. That it now shows you this is a good thing in 1.4.0 > because what was happening in the older versions is one of the sets of > processors was being loaded. You are probably seeing a warning in the > app log at startup. So depending on which nar is loaded first > (standard or your custom one) the code will actually run out of there. > So, in short the behavior in 1.4.0 even in your current setup is > probably better than the behavior prior. > > Hope that helps > > Thanks > Joe > > On Tue, Dec 26, 2017 at 2:00 PM, Byers, Steven K (Steve) CTR USARMY > MEDCOM JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > > Yes, I agree. Unfortunately, our schedule may not allow for that at this > time so we will probably have to put off migrating for now. > > > > Thanks to you and Bryan for your replies. > > > > Thank you, > > > > Steven K. Byers > > DXC Technology - Contractor > > Software Developer - Joint Medical Logistics Functional Development > Center (JMLFDC) > > Defense Health Agency (DHA)/ Health Information Technology (HIT) > Directorate/ Solution Delivery Division (SDD)/Clinical Support Branch/JMLFDC > > 1681 Nelson Street, Fort Detrick, MD 21702 > > (443) 538-7575 | (410) 872-4923 > > Email: steven.k.byers....@mail.mil > > > > > > > > -----Original Message----- > > From: Joe Witt [mailto:joe.w...@gmail.com] > > Sent: Tuesday, December 26, 2017 1:56 PM > > To: dev@nifi.apache.org > > Subject: Re: [Non-DoD Source] Re: Moving from version 1.1.2 to 1.4.0 > > > > Steven > > > > To Bryan's point if it will be best if you simply copy the code/base > classes over to your Nar rather than extending from existing concrete > implemented processors. > > > > Thanks > > > > On Tue, Dec 26, 2017 at 1:50 PM, Byers, Steven K (Steve) CTR USARMY > MEDCOM JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > >> Bryan, > >> > >> We have extended a few processors from standard processors. For > >> example, one of the processors we are extending is: > >> org.apache.nifi.processors.standard.JmsConsumer > >> > >> In another processor we are importing org.apache.nifi.processors. > standard.util.JdbcCommon. > >> > >> I tried making the dependency on standard processors optional > (optional>true</optional>) which excludes the standard processors but then > NiFi won't start because those custom processors that depend on it cannot > be instantiated. > >> > >> > >> > >> Thank you, > >> > >> Steven K. Byers > >> DXC Technology - Contractor > >> Software Developer - Joint Medical Logistics Functional Development > >> Center (JMLFDC) Defense Health Agency (DHA)/ Health Information > >> Technology (HIT) Directorate/ Solution Delivery Division > >> (SDD)/Clinical Support Branch/JMLFDC > >> 1681 Nelson Street, Fort Detrick, MD 21702 > >> (443) 538-7575 | (410) 872-4923 > >> Email: steven.k.byers....@mail.mil > >> > >> > >> > >> -----Original Message----- > >> From: Bryan Bende [mailto:bbe...@gmail.com] > >> Sent: Tuesday, December 26, 2017 1:34 PM > >> To: dev@nifi.apache.org > >> Subject: Re: [Non-DoD Source] Re: Moving from version 1.1.2 to 1.4.0 > >> > >> Can you give some more details about what the dependency is for? > >> > >> If it is some utility code that exists in standard processors then we > >> should be looking to move that to other reusable modules so that you > >> can depend on it without depending on the processors. > >> > >> If it is because you extended a processor from standard processors, > >> you would probably want to just copy the processor code into your own > >> NAR and modify/extend it. > >> > >> On Tue, Dec 26, 2017 at 1:26 PM Byers, Steven K (Steve) CTR USARMY > >> MEDCOM JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > >> > >>> Thanks for the reply, Bryan, > >>> > >>> Yes, two of our custom processors have a dependency on the standard > >>> processors. The dependency cannot be removed or those processors > >>> will not compile. > >>> > >>> Thank you, > >>> > >>> Steven K. Byers > >>> DXC Technology - Contractor > >>> Software Developer - Joint Medical Logistics Functional Development > >>> Center > >>> (JMLFDC) > >>> Defense Health Agency (DHA)/ Health Information Technology (HIT) > >>> Directorate/ Solution Delivery Division (SDD)/Clinical Support > >>> Branch/JMLFDC > >>> 1681 Nelson Street, Fort Detrick, MD 21702 > >>> (443) 538-7575 | (410) 872-4923 > >>> Email: steven.k.byers....@mail.mil > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Bryan Bende [mailto:bbe...@gmail.com] > >>> Sent: Tuesday, December 26, 2017 11:25 AM > >>> To: dev@nifi.apache.org > >>> Subject: [Non-DoD Source] Re: Moving from version 1.1.2 to 1.4.0 > >>> > >>> Hello, > >>> > >>> This means your custom NAR is bundling the standard processors jar > >>> and as a result they are getting discovered twice, once from your NAR > >>> and once from the standard NAR. > >>> > >>> You’ll have to look at your maven dependencies for your custom NARs > >>> and figure out why the dependency on standard processors exists and > remove it. > >>> > >>> Thanks, > >>> > >>> Bryan > >>> > >>> > >>> On Tue, Dec 26, 2017 at 11:09 AM Byers, Steven K (Steve) CTR USARMY > >>> MEDCOM JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > >>> > >>> > Hi devs, > >>> > > >>> > I'm looking into moving from NiFi 1.1.2 to 1.4.0. We have several > >>> > custom processors and services. Everything is compiling without > >>> > any problems but when I put the services into the 1.4.0 instance, > >>> > NiFi shows in the list of processors a 1.1.2 and 1.4.0 version of > >>> > all processors including the stock NiFi processors. If I just load > >>> > our custom processors that do not require a service, NiFi is fine > >>> > and the processor list looks like it should and the custom > >>> > processors work fine. It seems to be something related to the > >>> > custom services. Is there some documentation or any guidance > >>> > someone can provide to assist with what I am doing? > >>> > > >>> > Thank you, > >>> > > >>> > Steven K. Byers > >>> > DXC Technology - Contractor > >>> > Software Developer - Joint Medical Logistics Functional Development > >>> > Center > >>> > (JMLFDC) > >>> > Defense Health Agency (DHA)/ Health Information Technology (HIT) > >>> > Directorate/ Solution Delivery Division (SDD)/Clinical Support > >>> > Branch/JMLFDC > >>> > 1681 Nelson Street, Fort Detrick, MD 21702 > >>> > (443) 538-7575 | (410) 872-4923 > >>> > Email: steven.k.byers....@mail.mil > >>> > > >>> > > >>> > > >>> > -- > >>> Sent from Gmail Mobile > >>> > >> -- > >> Sent from Gmail Mobile > > >
