Change in properties for logging: deliberate?

[Jeremy Manson]

Thanks for the attention, Daniel.  You may want to consider adjusting it so
that the behavior of .level and .handlers are consistent with each other,
if they aren't...  I don't think that should break anyone significantly.

Jeremy

On Fri, Nov 10, 2017 at 1:20 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Jeremy,
>
> I will propose a fix then.
>
> However be aware that logging configuration files that use ".handlers"
> instead of "handlers" to configure the root logger are fragile, as it
> seems that any subsequent call to LogManager.readConfiguration() will
> remove this configuration. Though I agree this might not be an issue
> if it has stayed unnoticed for 15 years.
>
> I will need to verify the behavior of ".level".
> Thanks for pointing that out. I don't think it has the same flaw but
> I will need to make sure.
>
> best regards,
>
> -- daniel
>
> On 10/11/17 20:48, Jeremy Manson wrote:
>
>> Daniel,
>>
>> Thanks for taking a look at this.  I'd like to disagree with the
>> reasoning here.
>>
>> First, it isn't just JDKs 7 and 8 - the behavior is the same all the way
>> back to JDK 1.4, when the java.util.logging API was introduced.  So changes
>> affect 15 years' worth of logging configuration files.  For example, there
>> are no fewer than 350 instances of this pattern in our codebase.  Imagine
>> multiplying that across the entire world - everyone who is doing this has
>> to change their configuration.  That's a pretty big cost to introduce on
>> the developer community.
>>
>> This is worse on legacy systems, because the handlers property was broken
>> for a long time, and people basically had to use .handlers:
>> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6207335.
>>
>> Second, it is inconsistent for ".level" to work for level for the root
>> logger, and ".handlers" not to work for handlers for the root logger.  The
>> empty string represents the root logger, and having it only represent the
>> root logger sometimes is (to me) counterintuitive.  Without checking, my
>> suspicion is that .level behaves the same way as .handlers (that is, it is
>> only loaded once).  If we can live with the inconsistency there, we can
>> live with it here.  You can even document that that is the difference.
>>
>> Jeremy
>>
>>
>> On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>>     Hi Jason,
>>
>>     I have done a few tests with JDK 8 & 7.
>>
>>     I have created custom handlers and added some
>>     debug traces in their constructors and debug methods.
>>
>>     Then I have added these two lines to my logging.properties:
>>
>>     handlers = custom.Handler
>>     .handlers = custom.DotHandler
>>
>>     What I see is this:
>>
>>     - the first time the configuration is read, two handlers
>>        are added to the root logger:
>>        - an instance of DotHandler (first), then an instance
>>          of Handler (second).
>>
>>     Then if you call LogManager.readConfiguration() again,
>>     both handlers are closed, and this time only one
>>     instance of Handler is added to the root logger.
>>     No instance of DotHandler is added.
>>      From now on the property is ignored.
>>
>>     This is because the root logger is a special beast:
>>     it will not be removed (like all other loggers) when
>>     LogManager.readConfiguration() is called.
>>
>>     And as it happens, handlers are added to loggers
>>     when the loggers are added to the LogManager.
>>     As it happens, the ".handlers" property is only parsed
>>     and read when the root logger is added to the LogManager,
>>     and thus only once.
>>
>>     The "handlers" property on the other hand is parsed
>>     every time LogManager.readConfiguration() is called.
>>
>>     Given that, I suspect we should deprecate the use of
>>     ".handlers" for the root logger, as it appears that
>>     it has never worked properly. I could work on a patch
>>     for 10 (possibly backport it to 9 update) to preserve
>>     the strange behavior of 7 & 8, but is it worth it?
>>
>>     What are your thoughts?
>>
>>     best regards,
>>
>>     -- daniel
>>
>>
>>
>>
>>
>>     On 09/11/2017 19:50, Jason Mehrens wrote:
>>
>>         Daniel,
>>
>>         I would assume you would fix since it is advertised as a feature
>>         over here:
>>         https://docs.oracle.com/javase/1.5.0/docs/guide/logging/
>> changes.html
>>         <https://docs.oracle.com/javase/1.5.0/docs/guide/logging/
>> changes.html>
>>
>>         If it helps, I've dug up a lot of the history on this over here
>>         a while back:
>>         https://stackoverflow.com/questions/36726431/in-a-java-util-
>> logging-logging-properties-file-whats-the-difference-between-h
>>         <https://stackoverflow.com/questions/36726431/in-a-java-util
>> -logging-logging-properties-file-whats-the-difference-between-h>
>>
>>         I've updated that to include the links to this new issue.  Now
>>         that I've linked this message thread to that message thread that
>>         should crash the internet. :)
>>
>>         Jason
>>
>>         ________________________________________
>>         From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net
>>         <mailto:core-libs-dev-bounces at openjdk.java.net>> on behalf of
>>         Daniel Fuchs <daniel.fuchs at oracle.com
>>         <mailto:daniel.fuchs at oracle.com>>
>>         Sent: Thursday, November 9, 2017 1:29 PM
>>         To: mandy chung
>>         Cc: core-libs-dev at openjdk.java.net
>>         <mailto:core-libs-dev at openjdk.java.net>
>>         Subject: Re: Change in properties for logging: deliberate?
>>
>>         On 09/11/2017 19:16, mandy chung wrote:
>>
>>             Daniel - we should add this known issue in the release note
>>             and document
>>             the workaround.
>>
>>
>>         Hi Mandy,
>>
>>         Right, it either need to be fixed, or documented in the release
>>         notes. Let me first have a look at the issue though.
>>
>>         best regards,
>>
>>         -- daniel
>>
>>
>>
>>
>