river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
Date Sun, 04 Mar 2007 10:00:55 GMT
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:




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

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

View raw message