You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Russell Bateman <ru...@windofkeltia.com> on 2020/12/08 21:54:19 UTC
Okay to manage ComponentLog via ThreadLocal?
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
Re: Okay to manage ComponentLog via ThreadLocal?
Posted by Mark Payne <ma...@hotmail.com>.
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 <ma...@gmail.com> 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 <ru...@windofkeltia.com>
> 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 <ru...@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
>>
>>
Re: Okay to manage ComponentLog via ThreadLocal?
Posted by Mark Bean <ma...@gmail.com>.
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 <ru...@windofkeltia.com>
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 <ru...@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
>
>
Re: Okay to manage ComponentLog via ThreadLocal?
Posted by Russell Bateman <ru...@windofkeltia.com>.
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 <ru...@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
Re: Okay to manage ComponentLog via ThreadLocal?
Posted by Mark Payne <ma...@hotmail.com>.
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 <ru...@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