I’m AFK right now but I’m thinking there is a point in the lifecycle where you can expect a logger, and before that (like when the processor is instantiated as you have it coded), you may not be able to assume there is a logger (either in real NiFi or the mock-verse :)
My guess is the rule of thumb is that if you have a Context (either ProcessContext, ProcessorInitializationContext, ConfigurationContext, etc) then you can assume the logger is available, and just call getLogger() there. Sent from my iPhone > On Apr 12, 2018, at 5:27 PM, Russell Bateman <[email protected]> wrote: > > Thanks for responding, Andy. > > I am able to use it, like you, in onTrigger(). Where I haven't been able to > use it is from annotated methods (in the sense that onTrigger()isn't > annotated except by @Overridewhich is not relevant in this question). Imagine: > > public class Fun extends AbstractProcessor > { > private ComponentLog logger = getLogger(); > > @Override > public void onTrigger( final ProcessContext context, final ProcessSession > session ) throws ProcessException > { > logger.trace( "[PROFILE] onTrigger()" );*/* A */* > ... > } > > *@OnScheduled* > public void processProperties( final ProcessContext context ) > { > logger.trace( "[PROFILE] processProperties()" );*/* B */* > ... > } > > *@OnStopped* > public void dropEverything() > { > logger.trace( "[PROFILE] dropEverything()" );*/* C */* > ... > } > ... > } > > > Now, imaging suitable test code, FunTest.test() which sets up > > runner = TestRunners.newTestRunner( processor = new Fun() ); > > etc., then > > runner.run( 1 ); > > Above, instance A works fine (it's the one you illustrated in footnote [1]). > Instances B and C cause the error: > > java.lang.AssertionError: Could not invoke methods annotated with > @OnScheduled (or @OnStopped) annotation due to: > java.lang.reflect.InvocationTargetException > > Russ > >> On 04/12/2018 02:52 PM, Andy LoPresto wrote: >> Hi Russ, >> >> Are you saying the code that breaks is having “getLogger()” executed inside >> one of the processor lifecycle methods (i.e. GetFile#onTrigger()) or in your >> test code (i.e. GetFileTest#testOnTriggerShouldReadFile())? >> >> I’m not aware of anything with the JUnit runner that would cause issues >> here. I use the loggers extensively in both my application code [1] and the >> tests [2]. Obviously in the tests, I instantiate a new Logger instance for >> the test class. >> >> Can you share an example of the code that breaks this for you? >> >> [1] >> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/EncryptContent.java#L511 >> [2] >> https://github.com/apache/nifi/pull/2628/files#diff-e9cfa232683ae75b1fc505d6c9bd3b24R447 >> >> Andy LoPresto >> [email protected] <mailto:[email protected]> >> /[email protected] <mailto:[email protected]>/ >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >>> On Apr 12, 2018, at 3:46 PM, Russell Bateman <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I seem to crash NiFi JUnit test runner when I have code that calls >>> getLogger()or attempts to make use of the product of calling getLogger()in >>> situations where some context (probably) is missing like methods annotated >>> for call at "special" times. This makes sense, but is there a technique I >>> can use to profile my custom processor in order to observe (easily, such as >>> using the logger) the behavior of (i.e.: log-TRACE through) my processor in >>> respect to @OnScheduled, @OnUnscheduled, @OnStopped, etc. moments? >>> >>> Many thanks, >>> Russ >> >
