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

[Vitaly Davidovich]

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> 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
>