Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

Hi Martijn

Thank you for doing that. I'm afraid it is going to be hard enough 
anyway to keep myself updated on all feedback given :)
For me it is a matter of course that these kind of discussions should be 
held in the open. We are all stake holders in this.
As long as the discussion does not turn in to 'bike-shedding' or someone 
is deliberately trying to pervert the intention of the JEP I will try to 
keep it in the open as much as possible.

Cheers
/Fredrik

On 2014-05-18 13:26, Martijn Verburg wrote:
> Hi Fredrik,
>
> I've asked all of the discussions on our list to be fed back here or 
> directly to you. Thanks for opening the discussion, we really 
> appreciate it!
>
> Cheers,
> Martijn
>
> On Sunday, 18 May 2014, Fredrik Arvidsson 
> <fredrik.arvidsson at oracle.com <mailto:fredrik.arvidsson at oracle.com>> 
> wrote:
>
>     Hi Richard
>
>     I will add more text in the JEP describing the intent of the
>     hierarchical logger design. As you said, it is not that clear in
>     the current one. Thanks.
>
>     Regarding out off band discussions. I have noted that and I will
>     try to keep myself updated to that. It is not optimal to have
>     discussions in many places and I will not be able to screen all
>     the internets for this information. But this is what we have to
>     deal with I am afraid.
>
>     Cheers
>     /Fredrik
>
>     On 2014-05-18 11:47, Richard Warburton 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
>         <https://groups.google.com/a/jclarity.com/forum/#%21topic/friends/NA0EyOJk6bs>
>         <https://groups.google.com/a/jclarity.com/forum/#%21topic/friends/NA0EyOJk6bs>
>
>         regards,
>
>           Richard Warburton
>
>         http://insightfullogic.com
>         @RichardWarburto <http://twitter.com/richardwarburto>
>
>
>
>
> -- 
> Cheers,
> Martijn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140518/4d835a37/attachment.html>