RFR: 7159567 - inconsistent configuration of MemoryHandler (original) (raw)

Mandy Chung mandy.chung at oracle.com
Fri Sep 28 21:32:29 UTC 2012

On 9/28/2012 12:13 PM, Jim Gish wrote:

I've re-spun the change with additional usage notes in the spec to reflect the long-standing actual behavior. Note that it doesn't change the spec per se, as it was already stated in LogManager. This change simply replicates that language with an example in each *Handler class to make it easier to find.

Thanks for looking into it. This statement in LogManager does specify the properties for handlers:

The properties for loggers and Handlers will have names starting with the dot-separated name for the handler or logger.

Replicating that statement with an example is one way to do it. Would it be clearer if the prefix of the properties referenced in the bullet list is replaced from "java.util.logging" to some kind of prefix - something like this:

*Configuration:

*

This might add some clarity to the spec.

This is a spec bug fix that I would suggest to file a CCC to track for compatibility. I would also suggest running the JCK tests to find out if there is any regression due to this fix.

The webrev, as posted at http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/

See my comment above w.r.t. the spec change.

test/java/util/logging/MemoryHandler.java L27: "via via" typo L28: @run tag specifies the test name So it should be @run main/othervm MemoryHandler

L43: jtreg runs the test in a different working directory other than the test source. So the test has to read the system property ("test.src") to determine the location of the properties file. Typically, we will do this: String src = System.getProperty("test.src", ".); File fname = new File(src, LM_PROP_FNAME);

You don't need L44. You can reference LoggingDeadlock3.java test.

L51: this catch block to throw a RuntimeException doesn't seem necessary. If NPE is thrown, the test will fail anyway.

One suggestion to the test is to test both cases (one with the specified target handler and one without). You can define a custom target handler so that the test can verify if the expected one is used. A simple handler to count the number of log messages will do the work.

test/java/util/logging/MemoryHandlerTest.props I suggest to take out the comments and just keep the properties the test needs to make it easier to tell what's configured. Perhaps you should also specify java.util.logging.MemoryHandler.target to make sure that the custom handler with no target handler specified will not use j.u.l.MemoryHandler.target as the default.

Mandy

More information about the core-libs-dev mailing list