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

[Daniel Fuchs]

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

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.
Another possibility is to stick it in a local `logger` variable and call Reference.reachabilityFence(logger)  at the end of main() in order to prevent its garbage collection before main() exits...

Aside note: why `String.class.getName()`? is the logged message generated by java.lang.String? that would be dangerous - as strings are used all over the place in java.util.logging...

Oh - the issue is elsewhere, but since you are modifying the configuration of loggers you do need to run in /othervm too - so don't undo that change...

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

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