RFR (L): 8046148: JEP 158 Unified JVM Logging

[Max Ockner]

There would be at most one additional level of verbosity, which 
corresponds to calling the logging flag with "Verbose" or "WizardMode".  
In this case,  I'm not sure if there are any additional levels of verbosity.
On 9/11/2015 11:07 AM, Vitaly Davidovich wrote:
>
> So perhaps ClassLoading is too coarse a tag then? If you did have a 
> tag per class loading, unloading, constraints, etc are there also 
> verbosity levels within each?
>
> sent from my phone
>
> On Sep 11, 2015 10:12 AM, "Max Ockner" <max.ockner at oracle.com 
> <mailto:max.ockner at oracle.com>> wrote:
>
>
>     TL;DR at the bottom.
>
>     I have encountered some of the same issues with "levels" as many
>     of the other responders. Approximately half of the runtime team's
>     logging plans (all of the command line options) are made
>     significantly more complicated by the way levels are set up. The
>     other half of our logging requirements actually fit very well with
>     levels.
>
>     First I'll mention the pain points of converting to Unified
>     Logging. UL wants me to organize my logging messages by subsystem
>     (tag), which I completely agree with. However, each subsystem is
>     only allowed 5 nested logging commands even though it is most
>     common that a single subsystem has several disjoint types of
>     logging going on. Here is an example in which it makes more sense
>     to split a subsystem into 5 different tags than it does to use levels:
>
>     We have a ClassLoading system with quite a lot of stuff that can
>     be logged. ClassLoading, ClassUnloading, ClassLoaderData,
>     LoaderConstraints, ClassLoadingPreorder, and a couple more. If we
>     want all of these logging options to be accessible through the
>     ClassLoading tag (which we absolutely *do* want),  then we will
>     need to assign one logging feature per level. So which one is
>     Trace level? That is, which feature do we only want to see if
>     everything else is being printed as well?  What if we want to use
>     print LoaderConstraints on its own? With the given design, you
>     can't separate different types of logging in this way without
>     having entirely different tags.
>
>     Because of this, the runtime team plans to use a large number of
>     tags (more than 75 different tags) despite having nowhere close to
>     that many subsystems. There are also many instances of logging
>     options being called with "Verbose" or "WizardMode", which is
>     analogous to setting level=trace. An undesirable side effect of
>     this is if we want logging option X to have a default output and a
>     more verbose output,  then option X in its plain form is forced to
>     have a level lower than trace. We have had to compromise some of
>     the logging functionality so far by combining Verbose and
>     WizardMode so that there is at most one level of super verbose
>     info above any command line option.  Of course, it would be nice
>     to condense a lot of these options into single logging statements
>     for their respective subsystems, but this would majorly affect the
>     existing Java code for a lot of our customers as well as a lot of
>     developers.
>
>     On a more positive note, our error and warning level logging
>     messages fit much better into the UL framework since the subsystem
>     and severity of the error naturally imply which tag and level
>     should be used.
>
>     TL;DR:
>     -Levels help with structuring a lot of runtime's logging messages.
>     -Levels create undesirable constraints on some (half) of runtime's
>     logging messages.
>     -If users and developers weren't already using our command line
>     options in such delicate ways, it would be much easier for runtime
>     to bite the bullet and completely adhere to the tag=subsystem
>     convention.
>     - Unified Logging is good.
>
>     I hope this helps.
>     Max Ockner
>