<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
An issue with this maybe that access to the desktop is required<br class="">
in order to access the audio device even if it is there as<br class="">
that is how permissions may be set up to authenticate access<br class="">
and limit it to a single user.<br class=""></div></div></blockquote><div><br class=""></div><div>In this case we will check that the proper exception will be thrown.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
So tests being run in a non-headful environment - not quite<br class="">
the same thing as -Djava.awt.headless=true may be skipped<br class="">
even on systems that have audio. <br class=""></div></div></blockquote><div><br class=""></div><div>This is how it worked before the fix, because these tests were skipped, if there is no display, but the user had an access to the audio system.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
Were you logged in only as a remote user when executing these tests<br class="">
and if so did they have audio access if there was such a device ?<br class=""></div></div></blockquote><div><br class=""></div><div>I have checked intersections of:</div><div> - The user connect locally/remotly</div><div> - The user has an access to the Display or not.</div><div> - The user has an access to the audio system or not</div><div><br class=""></div><div>The tests will work properly when the user have correct access to the audio system. In other cases it will no-op.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
The combination of these factors and a lack of actual audio device<br class="">
may mean that we have all these tests being a useless no-op.<br class="">
<br class="">
-phil.<br class="">
<br class="">
On 3/25/17, 10:29 AM, Sergey Bylokhov wrote:
<blockquote cite="mid:EBC6C043-9B8B-445C-AFA1-48C7AA0291D3@oracle.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1" class="">
Hello,<br class="">
Please review the fix for jdk9.<br class="">
<div class="mod-content">
<div id="description-val" class="field-ignore-highlight">
<div class="user-content-block">Some tests in JavaSound were
marked by @headful key, but none of them use UI (headful
toolkit).
<br class="">
Looks like the root cause was in absent audio cards in test
systems, and the tests were not ready for that.
<br class="">
Example:
<br class="">
<a moz-do-not-send="true" href="http://mail.openjdk.java.net/pipermail/sound-dev/2015-August/000328.html" class="">http://mail.openjdk.java.net/pipermail/sound-dev/2015-August/000328.html</a>
</div>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">I have checked updated tests in the system with and
without Display and AudioCard.</div>
<div class="">If the tests will fail on some of our tests systems
then the reason is unrelated to the headful toolkit and should
be reported as a separate CR.</div>
<br class="">
Bug: <a moz-do-not-send="true" href="https://bugs.openjdk.java.net/browse/JDK-8177560" class="">https://bugs.openjdk.java.net/browse/JDK-8177560</a><br class="">
Webrev can be found at: <a moz-do-not-send="true" href="http://cr.openjdk.java.net/%7Eserb/8177560/webrev.00" class="">http://cr.openjdk.java.net/~serb/8177560/webrev.00</a>
</blockquote>
</div>
</div></blockquote></div><br class=""></body></html>