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 <r...@windofkeltia.com> 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
