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

Jaikiran Pai jpai at openjdk.java.net
Thu Oct 14 03:34:45 UTC 2021


On Wed, 13 Oct 2021 17:15:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> 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...

I had a look at the original issue for which this test was introduced https://bugs.openjdk.java.net/browse/JDK-8247907. As Max notes in that JBS issue, the bug was in log messages which are parameterized. Internally, the implementation of `com.sun.org.slf4j.internal.Logger` just delegates the calls to a `java.util.logging.Logger` and the fix was to properly transform the parameterization placeholders before passing on the calls to the `java.util.logging.Logger`[1]. So from what I understand, this `LogParameters` testcase is just there to test a parameterized log message through the `com.sun.org.slf4j.internal.Logger` and as such it doesn't matter what logger name (or class) is passed to create the logger instance. To avoid any confusion about the `String.class` usage for the logger instance, I have now updated the PR to use a different logger name (and class) while constructing the `java.util.logging.Logger` and `com.sun.org.slf4j.internal.Logger` instances. Additionally, I've added 
 some code comments in the test and also added a `@summary` to explain what this test does.

The test continues to pass with these changes.

[1] https://hg.openjdk.java.net/jdk/jdk/rev/216c6baa0564#l2.119

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

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



More information about the security-dev mailing list