RFR: 8254267: javax/xml/crypto/dsig/LogParameters.java failed with "RuntimeException: Unexpected log output:" [v2]

[Jaikiran Pai]

On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here tries to address an intermittent failure reported in https://bugs.openjdk.java.net/browse/JDK-8254267.
>> 
>> The `LogParameters` test case sets the log level to `ALL` for the `java.lang.String.class` and then attaches a handler to it. It then proceeds to write out a log message at `DEBUG` level and expects the log message to have been delivered to the handler.  This should all work fine and does work fine except for those intermittent failures.
>> 
>> Looking at the output attached in that JBS issue, there's this:
>> 
>> 
>> command: main LogParameters
>> reason: Assumed action based on file name: run main LogParameters
>> Mode: agentvm 
>> 
>> which states that the test is using `agentvm` mode, since the test itself doesn't specify a specific mode. For a test like this one which deals with log level management of `java.util.logging` infrastructure, in theory, there are chances that some other tests within the same JVM instance might impact the output and can potentially contribute to intermittent failures like this one.
>> 
>> The commit in this PR tries to address that issue by explicitly running the test in `othervm` mode.
>> 
>> P.S: Every once in a while my logins to JBS don't work and if I just wait for a few hours, things get sorted on its own. Today is one such occasion - successful login, but it still shows me as logged out and doesn't allow me to do anything. So I decided to directly create this PR instead of first commenting there.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year

Hello Daniel,

> You need to stick the logger returned by `Logger.getLogger(String.class.getName())` into a static variable to prevent it from being garbage collected. Indeed, if you don't do that, there will be only weak references to that logger, and the next call to `Logger.getLogger(String.class.getName())` might return a brand new instance. 

You are right. Good catch. I hadn't thought of that aspect at all. I've now updated the PR to create the logger instance in a static field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5927