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 each<tt>MemoryHandler</tt> is
initialized using the following LogManager configuration properties."
and then refers to "java.util.logging.<foo>" 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<handler-classname>.* 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.
*<b>Configuration:</b>
* By default each<tt>MemoryHandler</tt> 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.
*<ul>
*<li> java.util.logging.MemoryHandler.level
* specifies the level for the<tt>Handler</tt>
* (defaults to<tt>Level.ALL</tt>).
*<li> java.util.logging.MemoryHandler.filter
* specifies the name of a<tt>Filter</tt> class to use
* (defaults to no<tt>Filter</tt>).
*<li> java.util.logging.MemoryHandler.size
* defines the buffer size (defaults to 1000).
*<li> java.util.logging.MemoryHandler.push
* defines the<tt>pushLevel</tt> (defaults
to<tt>level.SEVERE</tt>).
*<li> java.util.logging.MemoryHandler.target
* specifies the name of the target<tt>Handler</tt> class.
* (no default).
*</ul>
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.g...@oracle.com
