JDK-8195974: Replace use of java.util.logging in javafx with System logger

Kevin Rushforth kevin.rushforth at oracle.com
Thu May 3 14:20:14 UTC 2018


>>     Also, why is webkit.mediaplayer special in its usage of the
>>     logger (that it requires its own property)?
>>
>
> That's the real question: are the needs of the WebView media component 
> so special that it justifies its own mechanism / property. I doubt it, 
> which is why removing the verbose flag altogether seems the better 
> choice as long as it isn't too intrusive / noisy.
> Is the intrusiveness something that needs to be and can be tested? Can 
> we remove the flag and if needed later reinstate it via a system property?

Yes, this seems OK to me.

>      it wouldn't surprise me that some of the WARNING log messages are
>     things that the user shouldn't necessarily be warned about.
>
>
> From my point of view, if the warning messages are of no interest to 
> the user, maybe they shouldn't be warning level.

Agreed. Some testing will be needed to see whether that is the case.

-- Kevin



On 5/3/2018 7:07 AM, Nir Lisker wrote:
>
>>         Also, why is webkit.mediaplayer special in its usage of the
>>         logger (that it requires its own property)?
>>
>
>     That's the real question: are the needs of the WebView media
>     component so special that it justifies its own mechanism /
>     property. I doubt it, which is why removing the verbose flag
>     altogether seems the better choice as long as it isn't too
>     intrusive / noisy.
>
> Is the intrusiveness something that needs to be and can be tested? Can 
> we remove the flag and if needed later reinstate it via a system property?
>
>      it wouldn't surprise me that some of the WARNING log messages are
>     things that the user shouldn't necessarily be warned about.
>
>
> From my point of view, if the warning messages are of no interest to 
> the user, maybe they shouldn't be warning level.

>
> - Nir


> On Thu, May 3, 2018 at 2:42 PM, Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>
>
>     On 5/2/2018 6:25 PM, Nir Lisker wrote:
>>
>>         Not sure what you mean by "that file".
>>
>>
>>     Sorry, I meant the log/config file.
>
>     I see. This isn't something that a library like JavaFX should read.
>
>>         keeping the verbose flag but putting it on a System property
>>
>>
>>     Then why not get a minimum level from a system property instead
>>     of a general on/off flag?
>
>     Because that would be duplicating functionality that should be
>     handled by the logger configuration itself (we can't set the
>     logging level when using the PlatformLogger wrapper utility to
>     System.Logger).
>
>>     Also, why is webkit.mediaplayer special in its usage of the
>>     logger (that it requires its own property)?
>
>     That's the real question: are the needs of the WebView media
>     component so special that it justifies its own mechanism /
>     property. I doubt it, which is why removing the verbose flag
>     altogether seems the better choice as long as it isn't too
>     intrusive / noisy.
>
>     -- Kevin
>
>
>
>>     - Nir
>>
>>     On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth
>>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>     wrote:
>>
>>         inline
>>
>>
>>         On 5/2/2018 4:52 PM, Nir Lisker wrote:
>>
>>             Thanks Murali,
>>
>>             I won’t suggest reading level value from log/config file.
>>
>>
>>             Is that file user facing? If so, wouldn't ignoring the
>>             level set in the
>>             file break current behavior? Would there need to be
>>             follow-up changes to
>>             this file to remove the level setting from it?
>>
>>
>>         Not sure what you mean by "that file". The WCMediaPlayer
>>         file? No, it isn't user-facing. Or did you mean something else?
>>
>>             About option (a), wouldn't removing the verbose flag
>>             (After changing INFO
>>             to FINE) cause all the log messages to appear by default,
>>             as you've stated
>>             in the first point, and we want to avoid that? We don't
>>             have a minimum log
>>             level setting.
>>
>>
>>         By default the log level for all loggers is set at INFO --
>>         thus the suggestion to change all of the INFO messages to
>>         FINE, which will not be logged by default. If we still end up
>>         with a bunch of extra WARNING or SEVERE log messages from
>>         from ordinary situations, then that would be a problem. Given
>>         that the implementation of WCMediaPlayer produces "noisier
>>         than typical" INFO log messages, it wouldn't surprise me that
>>         some of the WARNING log messages are things that the user
>>         shouldn't necessarily be warned about.
>>
>>         In any case, the second suggestion of keeping the verbose
>>         flag but putting it on a System property might be less
>>         intrusive. And like the current solution, puts the control in
>>         the hands of the user.
>>
>>         -- Kevin
>>
>>
>>             -Nir
>>
>>
>>             On Wed, May 2, 2018 at 11:21 PM, Murali Billa
>>             <murali.billa at oracle.com <mailto:murali.billa at oracle.com>>
>>             wrote:
>>
>>                 Hi Nir,
>>
>>
>>
>>                 1) Regarding “verbose” flag usage:
>>
>>                 ·  Currently verbose flag is used to show log Levels
>>                 (FINER/FINE/INFO/WARNING) in WCMediaPlayer &
>>                 WCMediaPlayerImpl.  I feel
>>                 it is not desirable to remove this flag as all these
>>                 logs will start
>>                 appearing now by default.
>>
>>                 ·         We can try 2 options:
>>
>>                 a)       1st Option: We can change all INFO log
>>                 messages to FINE  under
>>                 verbose flag (by leaving all log messages that use
>>                 Level other than INFO
>>                 unchanged) and verbose flag can be removed.
>>
>>                 b)      If 1st option results in too much noise for
>>                 WARNING log messages,
>>                 then we can keep the verbose flag and introduce a
>>                 System Property (for ex:
>>                 javafx.web.verbose) to enable the flag. I won’t
>>                 suggest reading level value
>>                 from log/config file.
>>
>>
>>
>>                 2) Regarding
>>                 “com.sun.javafx.webkit.drt.DumpRenderTree”, I need to
>>                 check few more things (since we use “addHandler” in
>>                 drt) and will get back
>>                 to you.
>>
>>
>>
>>                 Please let me know, if you have any queries for 1.
>>
>>                 Thanks,
>>
>>                 Murali
>>
>>                 *From:* Nir Lisker <nlisker at gmail.com
>>                 <mailto:nlisker at gmail.com>>
>>                 *Sent:* Saturday, April 28, 2018 1:06 AM
>>                 *To:* Murali Billa <murali.billa at oracle.com
>>                 <mailto:murali.billa at oracle.com>>
>>                 *Cc:* openjfx-dev at openjdk.java.net
>>                 <mailto:openjfx-dev at openjdk.java.net> Mailing
>>                 <openjfx-dev at openjdk.java.net
>>                 <mailto:openjfx-dev at openjdk.java.net>>
>>                 *Subject:* JDK-8195974: Replace use of
>>                 java.util.logging in javafx with
>>                 System logger
>>
>>
>>
>>                 Hi Murali,
>>
>>
>>
>>                 Can you have a look at
>>                 https://bugs.openjdk.java.net/browse/JDK-8195974
>>                 <https://bugs.openjdk.java.net/browse/JDK-8195974>
>>                 please?
>>
>>
>>
>>                 There are some usages of j.u.l in the web module I'd
>>                 like your opinion on.
>>                 I'm not familiar with the intent of these pieces of
>>                 code and would like to
>>                 know what the options are for advancing with this
>>                 issue on that front.
>>
>>
>>
>>                 Thanks,
>>
>>                 Nir
>>
>>
>>
>
>



More information about the openjfx-dev mailing list