Hi Staffan,
Thanks for the response.
You call it levels, I call is at hierarchy. I'm happy to change to the work
levels.
On 2012-08-17, at 10:20 PM, Staffan Larsen <staffan.lar...@oracle.com> wrote:
>
> On 15 aug 2012, at 16:19, Dmitry Samersoff <dmitry.samers...@oracle.com>
> wrote:
>
>> On 2012-08-15 12:44, Kirk Pepperdine wrote:
>>
>>> The current system of command-line (experimental) options follow a
>>> format that is quite consistent. The options provide semantic meaning as
>>> to what will be logged. This semantic meaning is lost when we reduce
>>> everything to the level of error, warning, info, debug and trace.
>>
>> I guess Levels are independent to categories. i.e. I think
>>
>> Log:info,gc,younggen should be possible
>
> The suggestion in the JEP is that each category/component has several levels,
> so in that sense they are not independent. To enable logging you would
> specify a list of {component, level} tuples, like:
>
> gc:info, younggen:trace
>
> But to make it easier to type in the most common case the 'info' level is
> considered 'default' if nothing else is specified. So the above would be
> equivalent to saying just
>
> gc, younggen:trace
Right, and this is at the heart of one of my objections is that the predefined
levels used by everyone lack semantic meaning where as being able to define
tags or groups of tags would allow one to define levels but not force one to
use levels. There certainly is a case for levels and I would not want them
precluded but I do not believe it is desirable for all components to
hierarchically reduce log messages.
If I had a better idea of the schedule for the JEP I'd have a better
understanding of when I might be able to pitch in rather then just play seagull.
Regards,
Kirk
