Russell, In 0.x, we had the ProcessorLog class, but it really was an "empty implementation" that extended ComponentLog. ProcessorLog is deprecated in the 0.x branch. You should be able to simply change any reference to ProcessorLog to ComponentLog, and it should still work in both 0.x and 1.x.
I don't believe you should be referencing MockProcessorLog or MockComponentLog directly. Rather, you should reference the ComponentLog interface. Once this is done, the code should work in both 0.x and 1.x. In general, unless you are referencing a deprecated class in 0.x, I don't believe you should have to make any code changes to move to 1.x. Thanks -Mark > On Nov 10, 2016, at 9:03 AM, Bryan Bende <[email protected]> wrote: > > Just to clarify... in 0.x there was "MockProcessorLog implements > ProcessorLog" which was refactored to "MockComponentLog implements > ComponentLog" during the 1.0 release as part of NIFI-1811. > > Also, in AbstractSessionFactoryProcessor in 0.x there was "ProcessorLog > getLogger()" which for 1.0 was refactored to "ComponentLog getLogger()" as > part of NIFI-1811. > > So I'm not sure that there would be a way to move to these changes without > building against 1.x. > > On Wed, Nov 9, 2016 at 5:51 PM, Russell Bateman < > [email protected]> wrote: > >> Bryan, >> >> Yes, today sees my first attempt at replacing 0.7.1 with 1.0.0 (in >> /pom.xml/) and at fixing all the errors. I think I am saying that >> >> ComponentLog logger = getLogger(); >> >> is resulting in errors, though I'm human and it could be my fault somehow. >> >> I had tried MockComponentLogback under 0.7.1, which doesn't exist there. >> We're standing on a code base we hope to move toward 1.x, but were also >> hoping, as is the case for ComponentLog, which did exist and we started >> migrating to it leaving ProcessorLogbehind, to retain source-code backward >> compatibility. In other words, build our source with 0.7.1 which is what >> we're running in production while with 1.x in forward (everyday) >> development. If we can't do this, it will mean that our move forward will >> be a rather more quantum (all or nothing) leap and we'll have to adjust >> accordingly. >> >> Thanks, >> >> Russ >> >> >> On 11/09/2016 03:37 PM, Bryan Bende wrote: >> >>> Hi Russell, >>> >>> As far as testing, I believe MockProcessorLog has been replaced with >>> MockComponentLog. >>> >>> For the second case, are you saying getLogger() is producing >>> NoSuchMethodErrors? >>> >>> Many processors do something like this: >>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/ >>> nifi-standard-bundle/nifi-standard-processors/src/main/ >>> java/org/apache/nifi/processors/standard/PutFile.java#L188 >>> >>> -Bryan >>> >>> On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman < >>> [email protected]> wrote: >>> >>> Also, I'm still having trouble with: >>>> >>>> public class LabIdentifier extends BaseIdentifierProcessor >>>> { >>>> // @formatter:off >>>> private LabIdentifierPropertiesMedical liProperties = new >>>> LabIdentifierPropertiesMedical(); >>>> * private ComponentLog log = getLogger();* >>>> >>>> causing NoSuchMethodErrors. I'm not finding clear examples out there of >>>> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby. >>>> >>>> Thanks. >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: MockProcessorLog in NiFi 1.0.0... >>>> Date: Wed, 9 Nov 2016 15:19:57 -0700 >>>> From: Russell Bateman <[email protected]> >>>> To: [email protected] >>>> >>>> >>>> >>>> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't >>>> figured >>>> out a way around this in my JUnit testing: >>>> >>>> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier >>>> (simulated)", SectionScoringIdentifierPropertiesTest.class ); >>>> >>>> >>>> MockProcessorLog causes a NoClassDefException, of course. What's the >>>> appropriate translation? >>>> >>>> Thanks, >>>> >>>> Russ >>>> >>>> >>>> >>>> >>
