Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

Hi all

On 2014-05-18 12:14, Kirk Pepperdine wrote:
> Hi Fredrik,
>
> I do need more information but I think a flat structure would provide less overhead rather than passing messages through a network of “sub” loggers.
Kirk, I can understand that you are concerned that the hierarchical 
structure would create unnecessary overhead, but it does not have to. 
With a good implementation design messages does not have to be passed 
through any other logger than the one it is logged to. I wont go in to 
any details here, but in my current poc implementation I think the code 
is quite efficient, even if I don’t have spent that much time on 
optimization yet. I think that having a good design that answers well to 
the requirements is better than doing premature sub optimization by 
crippling the design. Functionality first, optimization later, that's 
how I like to do it.

I will do my best to spend some time looking at Peters code, I am sure 
there are good things in there to consider.

Cheers
/Fredrik
> Peter Lawrey wrote JChronicle which at it’s core is a messaging system but it’s also a wickedly fast logger. That said, there isn’t a formalized logging interface to it though it’s something being discussed/thought about as we speak.
> https://github.com/peter-lawrey/Java-Chronicle.
>
> I’m not suggesting you take this implementation but there might be things to learn from it as this spec is being strengthened.
>
> Kind regards,
> Kirk Pepperdine
>
> On May 18, 2014, at 11:47 AM, Richard Warburton <richard.warburton at gmail.com> wrote:
>
>> Hi Fredrik,
>>
>> In the JEP I tried to explain the concept of 'sub' loggers but I did not
>>> put in anything about the intent of having them. I think that your
>>> requirement easily could be solved using sub loggers, or sub components if
>>> you like that wording better.
>>>
>>> Loggers are ordered in an hierarchical tree where 'gc' might be the root
>>> for all logging in the gc 'area'. The 'details', 'cause' and 'safepoint'
>>> content types could be translated in to sub loggers to the 'gc' logger. By
>>> setting log level for the separate sub loggers to enable logging I cant see
>>> that you would not be able to get the filtering you want. By using log
>>> levels wisely you will be able to get even more control over what gets
>>> output in the logs. The above was a much simplified example, in reality you
>>> would probably have a more elaborate tree of gc loggers. There is nothing
>>> in the logger three hierarchy approach that implies that they should be big
>>> blocks of stuff.
>>>
>>> Logging topics, tags, or markers were something we considered at the
>>> beginning of the design phase but we came to the conclusion that we
>>> probably could solve the requirements by using sub loggers instead.
>>>
>>> Please tell me if you don't think this approach would work, and in that
>>> case why.
>>>
>> Thanks for clarifying this point. I think this explanation addresses how
>> that particular use case is met. I suspect that it might be worth adding a
>> bit more explanation around this topic to the JEP itself, because I don't
>> think I'm the only person with this concern.
>>
>> Also a heads up that there's discussion happening related to this topic
>> off-list at:
>> https://groups.google.com/a/jclarity.com/forum/#!topic/friends/NA0EyOJk6bs
>>
>> regards,
>>
>>   Richard Warburton
>>
>>   http://insightfullogic.com
>>   @RichardWarburto <http://twitter.com/richardwarburto>