RFR: 7159567 - inconsistent configuration of MemoryHandler

[Mandy Chung]

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