Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging

[Mark Brouwer <ma...@cheiron.org>]

Hi Gregg,

Gregg Wonderly (JIRA) wrote:

> Gregg Wonderly commented on RIVER-13:
> -------------------------------------
> 
> Right, I see that the logger name is not set.  I do use a customer formatter as
 > the attached log entry indicates.  It includes the logger name so 
that you can
 > know what to turn down in log levels to stop a particular logger that 
is too
 > verbose.
> 
> I'm not sure of all the potential benefits of a hierarchy.  Here are some:
> {noformat}
> o  As I've discussed above, allow for messages with unused interfaces to be 
>     turned completely off.
> o  Allow a particular interface's messages to be routed through a particular
 > handler.
> {noformat}

Some more lessons in pretty issue formatting ;-) JIRA also supports
lists, by putting the star character on a new line in front of a list
item, 2 star characters for another level of indentation, etc.

  * item 1
  * item 2
   ** item 1 for item 2
   ** item 2 for item 2
  * item 3

You see in the end a JIRA issue can become as pretty as a Wikipedia page ...

BTW each field in JIRA that can take Wikipedia style formatting has a
preview icon and help icon to the right. By clicking preview you can see
the result of what you have edited and the help pops-up a window
explaining all the formatting options.

> I'm not sure how others use the logger name, but I use it for a wide
 > range of information and control in my applications.  I really find
 > value in having differentiation by logger name when logging applies
 > to devices or external entities that might be the responsibility of
 > different people or different organizations.

What I've seen is that most people use SimpleFormatter as it is the
default and that one doesn't display the logger name. I must admit
though a formatter that displays the logger name is a neat one, I'm
going to remember that. I guess most people have to rely on
documentation of which loggers they can turn on or off, etc.

FWIW in case of Seven I have an array of tools to filter such as
level range, type of exceptions, message content (regular expressions)
and service context, the latter is important if you have multiple
instances of services that use e.g. LookupDiscovery and you want to
display only the log records that are caused by that service.

And there lies to me the problem I have with hierarchy of loggers, I
tend to use them for subsystems in a piece of software and rely on other
means for filtering. If the hierarchy alone must be sufficient for
filtering then there are a lot of dimensions you want to capture in the
hierarchy and I'm afraid that won't be easy as people always tend to
look at things from different angles, also requirements change depending
on the problem you want to tackle or information to obtain.

Implementing your suggestion is likely not going to bring any help to
those stuck with SimpleFormatter (my guess most of the people) as it
would require a lot of explanation to help them pick the proper logger
name to turn it off. I'm inclined to see more value in making sure you
are not swamped by log messages for which the chance is 99% the problem
is not going away any time soon.

Likely introducing a hierarchy is not of any harm for most people who 
don't want to make use of the finer granularity of the logger names 
involved, but there is one serious drawback I can see for those 
utilizing log filtering features.

Assume we change the hierarchy from:

   n.j.d.LookupDiscovery

to

   n.j.d.LookupDiscovery.eth0.unicast
   n.j.d.LookupDiscovery.eth0.multicast
   n.j.d.LookupDiscovery.eth1.unicast
   n.j.d.LookupDiscovery.eth1.multicast

and I want to apply a filter so that only log record with a level of
exactly FINEST are logged for discovery then I can't no longer apply
that filter on the logger named "LookupDiscovery". I have to apply it to
all the 4 loggers, or even more when there are more than 2 interfaces.
This is due to the fact that filtering is only applied to a log record
on the Logger instance to which the LogRecord is presented, down the
hierarchy filtering doesn't work [1].

As you can see introducing an hierarchy can also make it harder to
perform filtering, therefore I'm very reluctant to introduce such an
hierarchy.

[1] assuming semantics of java.util.logging.Logger and not a subclass
that might provide different behavior.
-- 
Mark

Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging

[Mark Brouwer <ma...@cheiron.org>]

Craig L Russell wrote:
> 
> On Mar 4, 2007, at 3:20 PM, Gregg Wonderly wrote:
>> Mark Brouwer wrote:
> 
>>> and I want to apply a filter so that only log record with a level of
>>> exactly FINEST are logged for discovery
> 
> IIUC, you can never specify that only log records with FINEST are 
> logged. FINEST means to log all records that are equal to or more 
> important, including FINER, FINE, INFO, WARN, and SEVERE.

You can Craig, but you have to implement a java.util.logging.Filter (so
where I use "filter" I mean "applying a Filter"). I have a filter that
filters LogRecords of which the level is within a particular range so
you can also say: log all records of which the level is in the range of
FINEST - FINER, and believe it or not I've used them ;-)

You can also create filter chains that operate as AND/OR operations in
which you capture multiple dimension to which you want to look at your
log records.
-- 
Mark

Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging

[Craig L Russell <Cr...@Sun.COM>]

On Mar 4, 2007, at 3:20 PM, Gregg Wonderly wrote:
> Mark Brouwer wrote:

>> and I want to apply a filter so that only log record with a level of
>> exactly FINEST are logged for discovery

IIUC, you can never specify that only log records with FINEST are  
logged. FINEST means to log all records that are equal to or more  
important, including FINER, FINE, INFO, WARN, and SEVERE.

Craig

Craig Russell
DB PMC
clr@apache.org http://db.apache.org/jdo

Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging

[Mark Brouwer <ma...@cheiron.org>]

Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> Assume we change the hierarchy from:
>>
>>   n.j.d.LookupDiscovery
>>
>> to
>>
>>   n.j.d.LookupDiscovery.eth0.unicast
>>   n.j.d.LookupDiscovery.eth0.multicast
>>   n.j.d.LookupDiscovery.eth1.unicast
>>   n.j.d.LookupDiscovery.eth1.multicast
>>
>> and I want to apply a filter so that only log record with a level of
>> exactly FINEST are logged for discovery then I can't no longer apply
>> that filter on the logger named "LookupDiscovery".
> 
> The existing implementation of the java.util.logging allows you to say
> 
> net.jini.discovery.LookupDiscovery.level=FINEST
> 
> and that covers all in the hierarchy of names beyond that name.  Are you 
> referring to your filter mechanism that doesn't match the hierarchy?

Sorry for not being clear Gregg, another try.

I'm referring to an implementation of java.util.logging.Filter [1] that
is executed in the java.util.logging.Logger.log(LogRecord) method.
Opposed to the log level a filter are not inherited by a Logger from the
nearest parent that has a non-null Filter (semantics of Logger, so I'm
not deviating from the spec here).

When you create a deeper hierarchy of loggers for LookupDiscovery I
can't set these filters anymore on the LookupDiscovery node as the
logging will take place (at least that is what I assume) at a node that
is a child of LookupDiscovery, meaning I have to start setting filters
on each child node and that is my 'resistance' to a hierarchy in the
loggers for LookupDiscovery.

[1] Seven provides various implementation of java.util.logging.Filter
that can easily be applied to the logger nodes or log handlers, an
example is a regular expression filter so you can prevent from log
records that contain something like "network interface is bad" in their
message from being displayed. These can be applied during runtime to
troubleshoot.

BTW can you indicate whether when all the output is suppressed from the
incorrect configured or not disabled interfaces whether you still want
to have more hierarchy in the loggers.

> Also, my logman.dev.java.net project has an example formatter that is 
> used for logrecords displayed in its serviceUI.  One setting of 
> properties for the formatter causes it to display 
> [n.j.d.LookupDiscovery].  It uses the first letter of all the components 
> of the name except the last to shorten the display width.

Also neat feature Gregg, going to remember that one too, although there
is a chance of ambiguity when shortening the package names, but I guess
most times it won't be a problem.
-- 
Mark

Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging

[Gregg Wonderly <gr...@wonderly.org>]

Mark Brouwer wrote:
> Assume we change the hierarchy from:
> 
>   n.j.d.LookupDiscovery
> 
> to
> 
>   n.j.d.LookupDiscovery.eth0.unicast
>   n.j.d.LookupDiscovery.eth0.multicast
>   n.j.d.LookupDiscovery.eth1.unicast
>   n.j.d.LookupDiscovery.eth1.multicast
> 
> and I want to apply a filter so that only log record with a level of
> exactly FINEST are logged for discovery then I can't no longer apply
> that filter on the logger named "LookupDiscovery".

The existing implementation of the java.util.logging allows you to say

net.jini.discovery.LookupDiscovery.level=FINEST

and that covers all in the hierarchy of names beyond that name.  Are you 
referring to your filter mechanism that doesn't match the hierarchy?

Also, my logman.dev.java.net project has an example formatter that is used for 
logrecords displayed in its serviceUI.  One setting of properties for the 
formatter causes it to display [n.j.d.LookupDiscovery].  It uses the first 
letter of all the components of the name except the last to shorten the display 
width.

Gregg Wonderly