Mark, Thanks for reminding me to look into that. I’d seen it but hadn’t had a chance to dig in. Just made some comments.
Thanks -Mark > On Dec 9, 2020, at 11:27 AM, Mark Bean <[email protected]> wrote: > > This conversation reminded me I have a JIRA ticket [1] and corresponding > pull request [2] out there. It's been sitting idle for some time. Mark, > there was a question directed at you for thoughts. > > Any takers? > > [1] https://issues.apache.org/jira/browse/NIFI-7387 > [2] https://github.com/apache/nifi/pull/4225 > > Thanks, > Mark > > On Tue, Dec 8, 2020 at 5:10 PM Russell Bateman <[email protected]> > wrote: > >> Yes, well, I would consider that I had out-foxed myself, but it's >> probably due to not quite having all my fingers around the scope of the >> processor. I guess there's only one component logger for the currently >> executing NiFi instance? Yeah, I was thinking really hard about >> per-thread stuff, which is how I used this before. >> >> You're right. I swallowed the whole camel. >> >> Thanks, Mark! >> >> >> On 12/8/20 2:58 PM, Mark Payne wrote: >>> Russ, >>> >>> Why not just use: >>> >>> Public class Foo { >>> public void bar() { >>> ComponentLogger logger = CustomProcessor.getLogger(); >>> logger.warn( “This is a warning!” ); >>> } >>> } >>> >>> >>> Perhaps I’m missing something - or perhaps you made things simpler than >> they really are for demonstration purposes? >>> >>> Thanks >>> -Mark >>> >>> >>>> On Dec 8, 2020, at 4:54 PM, Russell Bateman <[email protected]> >> wrote: >>>> >>>> Because it's so onerous to pass a reference to the logger down through >> parameters lists, I thought I might try using Java's thread-local store. I >> haven't been using it for anything else either, but I thought I'd start. >> For now, the logger is the only thing that tempts me. In past lives as a >> web-application writer, I used it quite a bit. >>>> >>>> My question is, "Does this offend anyone who cares to give an opinion?" >> If there's a reason not to do this, I'll go to the effort (and muddy my >> parameter lists). Otherwise, I'll give it a try. >>>> >>>> >>>> public class CustomProcessor extends AbstractProcessor >>>> { >>>> private static ThreadLocal< ComponentLog > tls = new ThreadLocal<>(); >>>> >>>> public static ThreadLocal< ComponentLog > getTls() { return tls; } >>>> >>>> @Override >>>> public void onTrigger( final ProcessContext context, final >> ProcessSession session ) throws ProcessException >>>> { >>>> // grab the logger and store it on the thread... >>>> tls.set( getLogger() ); >>>> >>>> ... >>>> >>>> // we've finished using it--dump the logger... >>>> tls.remove(); >>>> } >>>> } >>>> >>>> public class Foo >>>> { >>>> public void bar() >>>> { >>>> ComponentLog logger = CustomProcessor.getTls().get(); >>>> logger.warn( "This is a warning!" ); >>>> } >>>> } >>>> >>>> Thanks for any opinions, statements of best practice, cat calls, >> sneers, etc. >>>> >>>> ;-) >>>> >>>> Russ >> >>
