Change in properties for logging: deliberate?

Daniel Fuchs daniel.fuchs at oracle.com
Sat Nov 11 00:22:32 UTC 2017


Hi Jeremy,

On 10/11/17 23:24, Jeremy Manson wrote:
> 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.

I think the way .handlers works in 7 and 8 (and probably earlier) is
a bug. It should work like "handlers" - but I am not sure it should
be changed now as some applications might depend on it: it seems
safer to simply fix 10 and 9 to match the earlier behavior and have
all releases work the same.


best regards,

-- daniel

> 
> Jeremy
> 
> On Fri, Nov 10, 2017 at 1:20 PM, Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto: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
>         <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>
>         <mailto: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>
>                 
>         <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>
>                 
>         <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>
>                  <mailto: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>
>                  <mailto: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>
>                  <mailto: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
> 
> 
> 
> 
> 



More information about the core-libs-dev mailing list