Need comments on JEP-158: Unified JVM Logging

[Kirk Pepperdine]

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.

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>