RFR: 7159567 - inconsistent configuration of MemoryHandler

[Jim Gish]

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.gish at oracle.com