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

Jim Gish jim.gish at oracle.com
Fri Sep 28 19:13:33 UTC 2012

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.

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

Thanks, Jim

On 09/27/2012 10:05 AM, Jim Gish wrote: > I agree. >> I reached the same conclusion, but wanted to see how others reacted. > Can we handle the spec change separate from the bug fix? If so, I'll > file another spec bug, and proceed with this fix. >> The key part of the current language that leaves this open and > undefined as it is is "By default eachMemoryHandler is > initialized using the following LogManager configuration properties." > and then refers to "java.util.logging." properties. >> Thanks, > Jim >> On 09/26/2012 10:44 PM, Mandy Chung wrote: >> Hi Jim, >>>> On 9/26/2012 2:19 PM, Jim Gish wrote: >>> Please review >>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-MemoryHandler-target/ >>> <http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-MemoryHandler-target/> >>>>>>>>> Overview - currently you can sub-class >>> java.util.logging.MemoryHandler and specify its configuration in a >>> logging.properties file via the classname. For example, if >>> com.foo.MyMemoryHandler extends MemoryHandler, you can have: >>>>>> logging.properties: >>>>>> com.foo.MyMemoryHandler.push=WARNING >>> com.foo.MyMemoryHandler.level=FINEST >> The current implementation does use the.* properties. >> However I couldn't find it from the j.u.logging specification. Did >> I miss any javadoc that mentions this? >>>> Per the j.u.l.MemoryHandler specification, it only reads >> "java.util.logging.MemoryHandler.*" properties but not the properties >> with the subclass name. >>>> *Configuration: >> * By default eachMemoryHandler is initialized using the >> following >> * LogManager configuration properties. If properties are not defined >> * (or have invalid values) then the specified default values are used. >> * If no default value is defined then a RuntimeException is thrown. >> *
     >> *
  • java.util.logging.MemoryHandler.level
    •  >> * specifies the level for theHandler >> * (defaults toLevel.ALL). >> *
  • java.util.logging.MemoryHandler.filter
    •  >> * specifies the name of aFilter class to use >> * (defaults to noFilter). >> *
  • java.util.logging.MemoryHandler.size
    •  >> * defines the buffer size (defaults to 1000). >> *
  • java.util.logging.MemoryHandler.push
    •  >> * defines thepushLevel (defaults >> tolevel.SEVERE). >> *
  • java.util.logging.MemoryHandler.target
    •  >> * specifies the name of the targetHandler class. >> * (no default). >> * >>>> I looked at the change history and found that the change to read >> property using the classname as the prefix (rather than >> j.u.l.MemoryHandler) >> was done in JDK 5 in the fix for 4635817. >>>> This isn't related to the bug you're fixing but I think this >> deserves to investigate whether this was an intended spec change >> at that time; if so, a spec update to clarify this behavior would >> be good. >>>> Thanks >> Mandy >>>

    Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com

    More information about the core-libs-dev mailing list