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.fu...@oracle.com
<mailto:daniel.fu...@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.fu...@oracle.com <mailto:daniel.fu...@oracle.com>
<mailto:daniel.fu...@oracle.com
<mailto:daniel.fu...@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-boun...@openjdk.java.net
<mailto:core-libs-dev-boun...@openjdk.java.net>
<mailto:core-libs-dev-boun...@openjdk.java.net
<mailto:core-libs-dev-boun...@openjdk.java.net>>> on behalf of
Daniel Fuchs <daniel.fu...@oracle.com
<mailto:daniel.fu...@oracle.com>
<mailto:daniel.fu...@oracle.com
<mailto:daniel.fu...@oracle.com>>>
Sent: Thursday, November 9, 2017 1:29 PM
To: mandy chung
Cc: core-libs-dev@openjdk.java.net
<mailto:core-libs-dev@openjdk.java.net>
<mailto:core-libs-dev@openjdk.java.net
<mailto:core-libs-dev@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
