Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] eXist logging information in the SSHTELNET MP logs

Subject: perfsonar development work

List archive

Re: [pS-dev] eXist logging information in the SSHTELNET MP logs


Chronological Thread 
  • From: "Michael Bischoff" <>
  • To: "Guilherme Fernandes" <>
  • Cc: "Stijn Melis" <>, "Roman Lapacz" <>, "" <>
  • Subject: Re: [pS-dev] eXist logging information in the SSHTELNET MP logs
  • Date: Wed, 18 Jun 2008 20:34:39 +0200 (CEST)
  • Importance: Normal

Hello Guilherme,

Actually I was a little to quick on the draw. The filtering I wanted to make
possible is
based upon the hierarchy of the Logger. My solution only makes %L / %c in the
pattern print
something usefull and thus doesn't solve the issue as the hierarchy is based
up the logger
name.

What (probably) Stijn and I wanted was the ability to do somethign like this:

org.perfsonar.base=INFO
org.perfsonar.service=DEBUG

in other words we only want the debug log of our service, while still getting
the INFO level
messages of the base.

Because we don't use the logger hierarchy at all we can't filter like that.
(We only define 4
or 5 loggers corresponding to the logging level.)

Anyways as I said, adleast using %L %l %C %F and/or %M should print
something useful now,
for example:

DEBUG: [18-06-2008 20:13:57] [Log4jLoggerComponent.java:89 debug()]
LSRegistrationComponent.initComponent: LSCleanupLoader: parameter
RUN_INTERVAL = 1800000
DEBUG: [18-06-2008 20:13:57] [Log4jLoggerComponent.java:89 debug()]
LSRegistrationComponent.initComponent: LSCleanupLoader: parameter
SCHEDULER = ma_scheduler

vs

DEBUG: [18-06-2008 20:25:55] [LSRegistrationComponent.java:272
initComponent()]
LSRegistrationComponent.initComponent: LSCleanupLoader: parameter
RUN_INTERVAL = 1800000
DEBUG: [18-06-2008 20:25:55] [LSRegistrationComponent.java:280
initComponent()]
LSRegistrationComponent.initComponent: LSCleanupLoader: parameter
SCHEDULER = ma_scheduler

Oh well it keeps my creative grep skills up.

Regards,

Michael

> Michael Bischoff wrote:
>
>> Hallo all,
>>
>>
>>
> Hi,
>
>> I'd hate to burst your(our) bubble but because of the way logging is run
>> as an auxiliary
>> component it registers the log statement as coming from the auxiliary
>> component and thus you
>> can't filter the results based upon which component(more correct: package)
>> they come from.
>>
>>
> For the debug level there was an "unspoken standard" to include the
> class/component name in the debug message, filtering could be done based on
> this (the actual
> auxiliary component should just be ignored). For the other levels I don't
> think this is a
> pertinent issue (the user should have to know which component is sending
> the messages).
>
> Of course this solution is cumbersome, all the developers need to take
> notice and remember to add it to every log.debug call. It would be nicer to
> have it done
> automatically by the logger component. Is that what you mean by "to
> accommodate filtering"?
>
> Regards,
>
>
> Guilherme
>
>
>
>> This is a serious?, well at least very tedious flaw in the current
>> perfsonar base.
>>
>>
>> I hope this is addressed in the new perfsonar base prototype.
>>
>>
>> Hmm I'm writing this message I wondered how http://www.slf4j.org/ fixes
>> this.
>>
>>
>> I stumbled upon this:
>> http://svn.slf4j.org/viewvc/slf4j/trunk/slf4j-log4j12/src/main/java/org/slf4j/impl/Log4jLog
>> gerAdapter.java?view=markup
>>
>> /**
>> * Following the pattern discussed in pages 162 through 168 of "The complete
>> * log4j manual".
>> */
>> final static String FQCN = Log4jLoggerAdapter.class.getName();
>>
>> I fixed the base to accommodate filtering when using log4j.
>>
>>
>> I'll see if I can upload a new version soon.
>>
>>
>> Kind regards,
>>
>>
>> Michael Bischoff
>>
>>
>>
>>>> Maybe we should implement a "perfsonar base debugging level". It can be
>>>> easily done with log4j, and both would actually log as DEBUG level, but
>>>> we can then
>>>> choose if we want only the debug info from our implementation, only the
>>>> one from base,
>>>> or both..
>>>>
>>> This seems like a good idea, although in practice I would probably still
>>> enable both most of the time (to see if the Authentication and LS
>>> Registration works for
>>> example).
>>>
>>> I can just remove the lines which are of no interest to me using some
>>> text editor, this would fix my problem as well :)
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Stijn
>>>
>>>
>>>
>>>
>>>> Guilherme
>>>>
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Stijn
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Roman
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stijn
>>>>>>>
>>>>>>>
>>>>>>>
>>
>>
>>
>
>




Archive powered by MHonArc 2.6.16.

Top of Page