RFR: 7159567 - inconsistent configuration of MemoryHandler

[Jim Gish]

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