<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
Beside of listed in the review tests there are another tests in the
folder. In case I'd update TEST.properties the not listed tests also
will get unnecessary dependency from java.logging.<br>
<br>
<font color="#999999"><span class="moz-txt-tag">-- <br>
</span>With best regards,
<br>
Sergei</font><br>
<br>
<blockquote type="cite">On 1 Nov 2016, at 18:40, Roger Riggs <<a
href="http://mail.openjdk.java.net/mailman/listinfo/net-dev">Roger.Riggs
at oracle.com</a>> wrote:
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">><i>
</i>><i> Hi,
</i>><i>
</i>><i> Ok, leave the logging in. (There are currently 3 issues marked as intermittent that refer to httpclient).
</i>><i>
</i>><i> Roger
</i>><i>
</i>><i> p.s. I'm also a fan of using the TEST.properties for test directives that apply to multiple tests
</i>><i> in a directory. In this case, "modules = java.logging”.
</i>
If I understand correctly, the list of ‘modules' in TEST.properties is only used
if the test does not explicitly have any @modules tags. So, if you want any
specific exports, or modules, then you need to specify them all.
-Chris.
><i>
</i>><i> On 11/1/2016 2:34 PM, Daniel Fuchs wrote:
</i>>><i> Hi Roger,
</i>>><i>
</i>>><i> I think we agree :-)
</i>>><i>
</i>>><i> On 01/11/16 18:01, Roger Riggs wrote:
</i>>>><i> Hi Daniel,
</i>>>><i>
</i>>>><i> It seemed useful to be able to run the test in as many environments as
</i>>>><i> possible
</i>>>><i> though realistically java.util.logging may be there too.
</i>>>><i>
</i>>>><i> I don't see that setting the logging levels is intrinsic to the tests
</i>>>><i> and would be used
</i>>>><i> for debugging so perhaps that function can be dropped or configured via the
</i>>>><i> java.util.logging.config.file system property if/when needed.
</i>>><i>
</i>>><i> For the java.util.logging.config.file system property to work then
</i>>><i> you would need java.logging to be linked in - so if you do want
</i>>><i> a test to spit out logging traces then you should require java.logging
</i>>><i> in @modules - whether you use logging.properties or programmatic
</i>>><i> interface to configure logging.
</i>>><i>
</i>>><i> So it all depends on how useful said traces are when investigating
</i>>><i> a test failure. If a test is known to fail intermittently and
</i>>><i> test failure would be very difficult to analyze without the logging
</i>>><i> traces then the test should probably require and configure java.logging
</i>>><i> upfront.
</i>>><i>
</i>>><i> Otherwise I agree you might want to remove the useless code, unless
</i>>><i> you do want to validate that no NPE or else happen while logging...
</i>>><i>
</i>>><i> best regards,
</i>>><i>
</i>>><i> -- daniel
</i>>><i>
</i>>><i>
</i>>>><i>
</i>>>><i> $.02, Roger
</i>>>><i>
</i>>>><i>
</i>>>><i>
</i>>>><i> On 11/1/2016 1:53 PM, Daniel Fuchs wrote:
</i>>>>><i> Hi Roger,
</i>>>>><i>
</i>>>>><i> On 01/11/16 17:21, Roger Riggs wrote:
</i>>>>>><i> Hi Sergei,
</i>>>>>><i>
</i>>>>>><i> I think it would be preferable to convert the tests to use
</i>>>>>><i> System.getLogger.
</i>>>>>><i> Is that possible?
</i>>>>><i>
</i>>>>><i> Some of the tests want to configure the logging, rather
</i>>>>><i> than simply produce traces - so they will need java.logging
</i>>>>><i> to do that:
</i>>>>><i>
</i>>>>><i> 670 Logger logger = Logger.getLogger("com.sun.net.httpserver");
</i>>>>><i> 671 ConsoleHandler ch = new ConsoleHandler();
</i>>>>><i> 672 logger.setLevel(Level.ALL);
</i>>>>><i> 673 ch.setLevel(Level.ALL);
</i>>>>><i> 674 logger.addHandler(ch);
</i>>>>><i>
</i>>>>><i> It's recommended to use System.Logger to log messages,
</i>>>>><i> but you will have to use java.util.logging if you want to configure
</i>>>>><i> the logging framework. Of course a library shouldn't do that,
</i>>>>><i> but a test is well in its right to configure logging to make
</i>>>>><i> sure the traces will appear in the log.
</i>>>>><i> Unless you do want to run the test in a VM that does not have
</i>>>>><i> java.logging linked in.
</i>>>>><i>
</i>>>>><i> cheers,
</i>>>>><i>
</i>>>>><i> -- daniel
</i>>>>><i>
</i>>>>><i>
</i>>>>>><i>
</i>>>>>><i> Thanks, Roger
</i>>>>>><i>
</i>>>>>><i>
</i>>>>>><i> On 11/1/2016 1:15 PM, Sergei Kovalev wrote:
</i>>>>>>><i> Hello all,
</i>>>>>>><i>
</i>>>>>>><i> Please review a small fix for tests.
</i>>>>>>><i>
</i>>>>>>><i> BugID: <a href="https://bugs.openjdk.java.net/browse/JDK-8169002">https://bugs.openjdk.java.net/browse/JDK-8169002</a>
</i>>>>>>><i> WebRev: <a href="http://cr.openjdk.java.net/%7Eskovalev/8169002/webrev.00/">http://cr.openjdk.java.net/~skovalev/8169002/webrev.00/</a>
</i>>>>>>><i>
</i>>>>>>><i> Issue: Several tests from java/net/httpclient folder have undeclared
</i>>>>>>><i> dependency on java.logging module. This issue leads the test to fail
</i>>>>>>><i> in case module limitation.
</i>>>>>>><i> Solution: added module declaration into jtreg header and organized
</i>>>>>>><i> imports.
</i></pre>
</blockquote>
</body>
</html>