)) {...}
without keeping a strong reference to the logger in the class.
In that case I guess it would be possible for that some-name
to appear transiently in the logger's name list - and be gc'ed
just after...
-- daniel
Mandy
On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
Hi,
Please find below an attempt
Hi,
Please find below a proposed fix for:
7184195 - java.util.logging.Logger.getGlobal().info()
doesn't log without configuration
Jim who was the original evaluator of this bug find out
that the root cause of the issue was that LogManager hadn't been
initialized yet, and therefore
to initialize the LogManager in different
manners.
-- daniel
On 6/19/13 5:31 PM, Daniel Fuchs wrote:
Hi,
Please find below a proposed fix for:
7184195 - java.util.logging.Logger.getGlobal().info()
doesn't log without configuration
Jim who was the original evaluator of this bug find out
On 6/19/13 8:25 PM, Mandy Chung wrote:
On 6/19/13 2:00 AM, Daniel Fuchs wrote:
On 6/13/13 10:05 PM, Mandy Chung wrote:
Daniel,
I wonder what the list of logger names (loggers1 and loggers2) returned
by LoggingMXBean contains and that may include loggers in the running VM
other than the ones
On 6/20/13 12:50 PM, Daniel Fuchs wrote:
Right. I have changed the test to temporarily retrieve the named loggers
and keep them in an HashMap - this way they should not be gc'ed.
Wrong URL, sorry:
http://cr.openjdk.java.net/~dfuchs/JDK-8014045/webrev.02/
-- daniel
Hi,
Please find below a patch for jdk8 for:
8017174 - NPE when using Logger.getAnonymousLogger or
LogManager.getLogManager().getLogger
http://cr.openjdk.java.net/~dfuchs/JDK-8017174/webrev-jdk8.00/
The issue was that the lazy initialization of LoggerContext was
not working correctly -
Changeset: 3aa541b50a64
Author:dfuchs
Date: 2013-07-01 11:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3aa541b50a64
8014045: test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
failing intermittently
Summary: this test was failing because it didn't
On 6/28/13 9:37 PM, Mandy Chung wrote:
Hi Daniel,
On 6/19/2013 8:31 AM, Daniel Fuchs wrote:
The fix proposed is simple. In getGlobal() we check whether
the 'manager' variable is null - and if it is, we initialize it
by calling LogManager.getLogManager().
This is a pattern which is already
to log that as a separate issue. But this is definitely
something I want to investigate in the short term.
Would that be OK with you Peter?
best regards,
-- daniel
Mandy
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018518.html
Regards, Peter
On 06/19/2013 05:31 PM, Daniel
tests summary.
added . as default value for test.src.
http://cr.openjdk.java.net/~dfuchs/JDK-7184195/webrev.02/
Hope you find it more to your liking!
Best regards,
-- daniel
On 7/1/13 7:57 PM, Mandy Chung wrote:
On 7/1/13 6:25 AM, Daniel Fuchs wrote:
Looks good in general. Some comments
Changeset: 020f023f87d1
Author:dfuchs
Date: 2013-07-02 11:30 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/020f023f87d1
8017174: NPE when using Logger.getAnonymousLogger or
LogManager.getLogManager().getLogger
Summary: This patch makes sure that LoggerContext instances
Changeset: 70bff2d12af0
Author:dfuchs
Date: 2013-07-02 19:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70bff2d12af0
7184195: java.util.logging.Logger.getGlobal().info() doesn't log without
configuration
Summary: Due to subtle synchronization issues between LogManager
Hi,
Please find below a changeset for fixing
8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
failing intermittently [1]
This appears to be a test bug due to a bizarre use of synchronization
in the test. The test was failing regularly before the fix (= often
enough),
On 7/23/13 6:07 PM, Mandy Chung wrote:
On 7/23/2013 9:08 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset for fixing
8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java
is failing intermittently [1]
This appears to be a test bug due to a bizarre use
Hi Joe,
This looks reasonable.
Out of curiosity - could it be that it was fSAXParser that was null,
and not fSecurityPropertyMgr?
JAXPSAXParser has a no arg public constructor that could have lead to
that...
I have only one remark:
It looks as if fSecurityPropertyMgr could be declared
Hi David,
On 7/24/13 1:48 PM, David Holmes wrote:
On 23/07/2013 11:08 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset for fixing
8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
failing intermittently [1]
This appears to be a test bug due to a bizarre use
code paths too.
I agree with this change, and Daniel's comments to make both
fSecurityPropertyMgr fields final. Consider it reviewed ( at least
on my side ).
-Chris.
On 24/07/2013 07:59, huizhe wang wrote:
On 7/23/2013 11:00 PM, Daniel Fuchs wrote:
Hi Joe,
This looks reasonable.
Out
Hi,
For the record I have updated the webrev with Mandy's suggestion:
http://cr.openjdk.java.net/~dfuchs/webrev_8019948/webrev.01/
-- daniel
On 7/23/13 6:07 PM, Mandy Chung wrote:
On 7/23/2013 9:08 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset for fixing
8019948: java/util
Changeset: 78c102c3eefc
Author:dfuchs
Date: 2013-08-13 16:00 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78c102c3eefc
8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is
failing intermittently
Reviewed-by: mchung, dholmes
!
Hi,
Please find below a fix for:
8005899: Logger.getLogger(name, null) should not allow to reset
a non-null resource bundle
The issue here is that whereas in JDK 7,
Logger.getLogger(foo, null);
will throw an IllegalArgumentException if foo has a non null
bundle name, JDK 8 will
.
Thanks Lance and Mandy!
I have updated the webrev as per your suggestion:
http://cr.openjdk.java.net/~dfuchs/webrev_8005899/webrev.01/
-- daniel
thanks
Mandy
On 8/23/2013 7:41 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8005899: Logger.getLogger(name, null) should not allow
Changeset: 4ef82445ea20
Author:dfuchs
Date: 2013-08-23 20:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ef82445ea20
8005899: Logger.getLogger(name, null) should not allow to reset a non-null
resource bundle
Reviewed-by: mchung, lancea
!
Hi,
This is a fix for an old bug which rightfully remarks that
whereas access to 'level' in handler is synchronized,
access to other mutable fields - like 'filter' etc...
is not - which is inconsistent.
http://cr.openjdk.java.net/~dfuchs/webrev_6823527/webrev.00/
I have tried to keep the fix
no
practical way to ascertain that.
Wait for a true core-libs Reviewer before pushing this one. :)
David
On 29/08/2013 8:42 PM, Daniel Fuchs wrote:
Hi,
This is a fix for an old bug which rightfully remarks that
whereas access to 'level' in handler is synchronized,
access
Hi Jason,
Yes - that makes sense. I think we want the setter to use the
same lock than e.g. publish because we don't want the level
(or filter or encoding or whatever) to be changed while
publish is executing.
However I see no harm in allowing other threads to read the
variables values while
On 8/29/13 5:38 PM, Daniel Fuchs wrote:
Hi Jason,
Yes - that makes sense. I think we want the setter to use the
same lock than e.g. publish because we don't want the level
(or filter or encoding or whatever) to be changed while
publish is executing.
However I see no harm in allowing other
On 8/29/13 7:58 PM, Mandy Chung wrote:
On 8/29/13 9:46 AM, Daniel Fuchs wrote:
Here is the new webrev implementing Jason's suggestion.
Compared to previous webrev only Handler.java StreamHandler.java
have changed.
http://cr.openjdk.java.net/~dfuchs/webrev_6823527/webrev.01/
Looks good. I
: daniel.fu...@oracle.com
To: core-libs-dev@openjdk.java.net
Subject: Re: RFR: JDK-6823527: java.util.logging.Handler has thread
safety issues
On 8/29/13 5:38 PM, Daniel Fuchs wrote:
Hi Jason,
Yes - that makes sense. I think we want the setter to use the
same lock than e.g
On 8/29/13 9:45 PM, Mandy Chung wrote:
On 8/29/13 11:04 AM, Daniel Fuchs wrote:
On 8/29/13 7:58 PM, Mandy Chung wrote:
On 8/29/13 9:46 AM, Daniel Fuchs wrote:
Here is the new webrev implementing Jason's suggestion.
Compared to previous webrev only Handler.java StreamHandler.java
have changed
Hi,
Please find below a changeset that will fix:
8019853 - Break logging and AWT circular dependency
(which also duplicates
8023258 Logger.getLogger() after ImageIO.read() returns
different logger instance)
http://cr.openjdk.java.net/~dfuchs/webrev_8019853/webrev.00/
The new code
lean to either b) or c).
-- daniel
David
On 30/08/2013 5:54 AM, Daniel Fuchs wrote:
On 8/29/13 9:45 PM, Mandy Chung wrote:
On 8/29/13 11:04 AM, Daniel Fuchs wrote:
On 8/29/13 7:58 PM, Mandy Chung wrote:
On 8/29/13 9:46 AM, Daniel Fuchs wrote:
Here is the new webrev implementing Jason's
preference would lean to either b) or c).
On 8/30/13 10:38 AM, Daniel Fuchs wrote:
On 8/30/13 9:21 AM, David Holmes wrote:
Hi Daniel,
I'm fine with the approach in (c), just wanted to highlight the
performance considerations (volatile and synchronized need not be
equivalent in the uncontended case
On 8/30/13 7:04 PM, Jason Mehrens wrote:
The coarse grain locking in FileHandler, MemoryHandler, SocketHandler,
and StreamHandler publish could/should be relaxed so we are not calling
isLoggable while holding the lock.
Hi Jason,
I'm not sure I'd want to attempt that. Modifications in logging
Hi,
Please find below a fix for:
8016127: NLS: logging.properties translatability recommendation
http://cr.openjdk.java.net/~dfuchs/webrev_8016127/webrev.03/
This fix corrects localized Level names in JDK 8.
It updates the logging.properties resource bundles to follow
internationalization
On 9/2/13 4:00 PM, Alan Bateman wrote:
On 02/09/2013 14:29, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8016127: NLS: logging.properties translatability recommendation
http://cr.openjdk.java.net/~dfuchs/webrev_8016127/webrev.03/
One thing I notice is that you've changed
Changeset: 92d594a938ff
Author:dfuchs
Date: 2013-09-02 18:28 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d594a938ff
8016127: NLS: logging.properties translatability recommendation
8024131: Issues with cached localizedLevelName in java.util.logging.Level
Summary: This
6:29 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8016127: NLS: logging.properties translatability recommendation
http://cr.openjdk.java.net/~dfuchs/webrev_8016127/webrev.03/
This fix corrects localized Level names in JDK 8.
It updates the logging.properties resource bundles
Changeset: ac6e99af2056
Author:dfuchs
Date: 2013-09-04 15:32 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac6e99af2056
6823527: java.util.logging.Handler has thread safety issues
Reviewed-by: dholmes, mchung
! src/share/classes/java/util/logging/ConsoleHandler.java
!
Changeset: b3d6953b9829
Author:dfuchs
Date: 2013-09-04 16:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829
8019853: Break logging and AWT circular dependency
Summary: Break logging and AWT circular dependency, which was at the root cause
for 8023258 -
Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.00/
LogManager class initialization is fragile: because Logger
constructor calls
Hi Mandy,
On 9/5/13 2:46 AM, Mandy Chung wrote:
On 9/4/2013 12:56 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
http://cr.openjdk.java.net/~dfuchs/webrev_8023168
Hi David,
Thanks a lot for your feedback!
On 9/4/13 11:36 PM, David M. Lloyd wrote:
As far as calling initialization (ensureLogManagerInitialized()),
it's a shame that checking for a one-time action has to run through a
synchronization block every time. Maybe a lazy holder class would
be
On 9/5/13 8:07 AM, Peter Levart wrote:
On 09/04/2013 11:36 PM, David M. Lloyd wrote:
On 09/04/2013 02:56 PM, Daniel Fuchs wrote:
Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
http
On 9/5/13 1:51 PM, Peter Levart wrote:
Threads that call ensureLogManagerInitialized() after that will find
the flag
is true before entering the synchronized block and will return directly.
...and such threads can see rootLogger field being either still null or
not null but the Logger instance
NetBeans configuration to run NetBeans 7.3 over
my private build - and I'm not seeing any troubles either so far.
(I had done that with the previous patch too)
best regards,
-- daniel
On 9/5/13 2:43 PM, Daniel Fuchs wrote:
On 9/5/13 1:51 PM, Peter Levart wrote:
Threads that call
Yes - I'd seen it and intended to fix it and then I forgot.
Sorry for that. I will clean that up when I get the chance.
-- daniel
On 9/5/13 6:46 PM, Andrew Hughes wrote:
- Original Message -
Am 04.09.2013, 16:54 Uhr, schrieb daniel.fu...@oracle.com:
URL:
Hi Peter,
On 9/5/13 7:15 PM, Peter Levart wrote:
On 09/05/2013 02:43 PM, Daniel Fuchs wrote:
On 9/5/13 1:51 PM, Peter Levart wrote:
Threads that call ensureLogManagerInitialized() after that will find
the flag
is true before entering the synchronized block and will return
directly
.
You have some typos:
LogMnager
initalization
initializationCalled
+ *
+ **/
=
*/
On Thu, Sep 5, 2013 at 7:43 AM, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
Hi,
Here is the new patch. It uses an additional volatile flag
to avoid
New webrev.
Has Martin's comments + simplified Logger.getGlobal().
Rest left unchanged. Tests are running...
http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.02/
cheers,
-- daniel
On 9/5/13 8:16 PM, Daniel Fuchs wrote:
Hi Peter,
On 9/5/13 7:15 PM, Peter Levart wrote:
On 09/05
Hi Mandy,
Thanks for the feedback!
On 9/6/13 4:28 AM, Mandy Chung wrote:
On 9/5/2013 11:51 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.02/
Logger.java - I like this and much cleaner fix.
251 // because global.manager will become not null
Hi,
Here is a new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.03/
It incorporates Mandy comments in the following way:
1. somewhen = somewhere
2. setLogManager method comment updated
3. checkPermission left unchanged (nothing done - as it is unclear
that
Changeset: 4afdf10de648
Author:dfuchs
Date: 2013-09-09 13:59 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4afdf10de648
8023168: Cleanup LogManager class initialization and LogManager/LoggerContext
relationship
8021003:
Hi,
Please find below a changeset for a small logging RFE:
8024525 - Make Logger log methods call isLoggable()
http://cr.openjdk.java.net/~dfuchs/webrev_8024525/webrev.00/
This change makes the various Logger logging method call isLoggable()
instead of simply inlining the checks.
This should
Hi,
New changeset incorporating Alan's feedback:
http://cr.openjdk.java.net/~dfuchs/webrev_8024525/webrev.01/
How/why the test works should now appear more clearly :-)
-- daniel
On 9/12/13 10:40 AM, Alan Bateman wrote:
On 11/09/2013 18:59, Daniel Fuchs wrote:
Hi,
Please find below
Changeset: 631c8dcd91f4
Author:dfuchs
Date: 2013-09-12 17:01 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631c8dcd91f4
8024525: Make Logger log methods call isLoggable()
Summary: This changeset makes the various Logger logging method call
isLoggable() instead of inlining
Hi,
Please find below a patch for:
8013839: Enhance Logger API for handling of resource bundles, and
4814565: (rb) add method to get basename from a ResourceBundle
http://cr.openjdk.java.net/~dfuchs/webrev_8013839/webrev.06/
1. It adds a ResourceBundle.getBaseBundleName() method,
2. It
Changeset: 76619d71a7c5
Author:dfuchs
Date: 2013-09-25 09:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76619d71a7c5
8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout
Summary: Arbitrary timeouts in the tests @run lines where too agressive
On 10/3/13 5:32 PM, Mandy Chung wrote:
Hi Daniel,
On 10/3/2013 7:47 AM, Daniel Fuchs wrote:
The new webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8013839/webrev.07/
Looks good. Thanks for improving the javadoc.
line 1264 formatting nits - there are extra spaces that can
Hi Mandy,
On 10/3/13 9:29 PM, Mandy Chung wrote:
test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
109 return new VectorString(java.util.Arrays.asList(
110 new String[] {dummy})).elements();
Could you use
Changeset: f031b2fe21cd
Author:dfuchs
Date: 2013-10-04 19:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f031b2fe21cd
8025745: Clarify API documentation of JAXP factories.
Summary: Clarifies usage of ServiceLoader in JAXP factories.
Reviewed-by: alanb, joehw, psandoz
!
Hi Alan,
The com.sun.management changes look good.
-- daniel
On 10/6/13 10:03 PM, Alan Bateman wrote:
As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,
I'd like to have another attempt at adding the annotation to a number of
JDK specific APIs that are long standing
Hi,
Please find below a fix for:
8024704: Improve API documentation of ClassLoader and ServiceLoader
with respect to enumeration of resources.
https://bugs.openjdk.java.net/browse/JDK-8024704
This is a clarification of the implementation of the
ServiceLoader.iterator() method, as well
On 10/9/13 2:39 AM, Mandy Chung wrote:
This fixes Level.parse to return the custom Level instance.
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.00/
When a custom Level is created, a mirrored level instance (containing
the same value as the custom Level) is created
/webrev_8024704/webrev.01/
-- daniel
On 10/8/13 10:06 PM, Alan Bateman wrote:
On 08/10/2013 18:19, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8024704: Improve API documentation of ClassLoader and ServiceLoader
with respect to enumeration of resources.
https
Hi Mandy,
This looks good!
(not a reviewer)
-- daniel
On 10/9/13 12:29 PM, Mandy Chung wrote:
Daniel,
Thanks for the review.
On 10/9/2013 12:38 AM, Daniel Fuchs wrote:
This looks good - but I think you could move the changes line 554-562 and
put them back inside the KnownLevel constructor
Hi Joe,
I don't know what was the original format but these changes
look reasonable.
best regards,
-- daniel (not a reviewer)
On 10/9/13 7:35 PM, huizhe wang wrote:
Hi,
These resource bundles in JAXP were refactored due to request by WPTG.
Now that the WPTG tool has been approved to support
Hi,
Please find below a patch for
8011638 - Remove deprecated methods in sun.util.logging.PlatformLogger
https://bugs.openjdk.java.net/browse/JDK-8011638
http://cr.openjdk.java.net/~dfuchs/webrev_8011638/webrev.00/
best regards,
-- daniel
On 10/4/13 4:44 PM, Daniel Fuchs wrote:
Hi Mandy,
On 10/3/13 9:29 PM, Mandy Chung wrote:
test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java
109 return new VectorString(java.util.Arrays.asList(
110 new String[] {dummy
Changeset: 9f8bfdd99129
Author:dfuchs
Date: 2013-10-14 10:42 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8bfdd99129
8024704: Improve API documentation of ClassLoader and ServiceLoader with
respect to enumeration of resources.
Reviewed-by: alanb, psandoz, mchung
!
Hi,
Please find below a fix for:
8026404: Logging in Applet can trigger ACE:
access denied (java.lang.RuntimePermission
modifyThreadGroup)
In some circumstances the call to JavaAWTAccess.getAppletContext()
will trigger a call to ecx.threadGroup.getParent() == null
The
Adding awt-dev...
The change looks okay to me but I would suggest sending to awt-dev so that the
folks that maintain this area know about it.
On the test then does initializing SunToolkit cause AWT to be initialized? I
just wonder if this test will run headless.
-Alan.
Hi,
Please find
Hi David,
On 10/15/13 9:38 AM, David Holmes wrote:
On 15/10/2013 5:19 AM, Daniel Fuchs wrote:
Adding awt-dev...
The change looks okay to me but I would suggest sending to awt-dev so
that the folks that maintain this area know about it.
On the test then does initializing SunToolkit cause AWT
Changeset: 2c16140fb515
Author:dfuchs
Date: 2013-10-15 13:01 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c16140fb515
8026404: Logging in Applet can trigger ACE: access denied
(java.lang.RuntimePermission modifyThreadGroup)
Summary: The test 'threadGroup.getParent() ==
Hi,
Please find below a fix for:
8026499: Root Logger level can be reset unexpectedly
https://bugs.openjdk.java.net/browse/JDK-8026499
http://cr.openjdk.java.net/~dfuchs/webrev_8026499/webrev.00/
The issue here is that calling a method like e.g. URL.openConnection()
will trigger the
Hi Mandy,
On 10/16/13 12:58 AM, Mandy Chung wrote:
On 10/15/2013 9:48 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8026499: Root Logger level can be reset unexpectedly
https://bugs.openjdk.java.net/browse/JDK-8026499
http://cr.openjdk.java.net/~dfuchs/webrev_8026499
, Daniel Fuchs wrote:
Hi Mandy,
On 10/16/13 12:58 AM, Mandy Chung wrote:
On 10/15/2013 9:48 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8026499: Root Logger level can be reset unexpectedly
https://bugs.openjdk.java.net/browse/JDK-8026499
http://cr.openjdk.java.net
Changeset: 445667b19e32
Author:dfuchs
Date: 2013-10-16 17:19 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445667b19e32
8011638: Remove deprecated methods in sun.util.logging.PlatformLogger
Reviewed-by: psandoz, mchung, alanb, chegar
!
Changeset: 2ef43f3a901c
Author:dfuchs
Date: 2013-10-16 20:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ef43f3a901c
8013839: Enhance Logger API for handling of resource bundles
4814565: (rb) add method to get basename from a ResourceBundle
Summary: adds
Hi,
Please find below a fix for:
8016344: (props) Properties.storeToXML behaviour has changed from
JDK 6 to 7
The code for storing properties to XML has changed significantly
between 7 8 - but the bug is still present in 8...
This is the fix for JDK 8.
By default
://cr.openjdk.java.net/~dfuchs/webrev_8016344/webrev.01/
-- daniel
Mandy
On 10/17/13 9:18 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for:
8016344: (props) Properties.storeToXML behaviour has changed from
JDK 6 to 7
The code for storing properties to XML has changed
On 10/18/13 1:38 PM, Paul Sandoz wrote:
On Oct 18, 2013, at 1:15 PM, Daniel Fuchs daniel.fu...@oracle.com wrote:
On 10/17/13 8:12 PM, Mandy Chung wrote:
Daniel,
Have you considered to revert to the previous version and simply iterate
props.keySet rather than adding a new entry point just
On 10/18/13 2:08 PM, Alan Bateman wrote:
On 18/10/2013 12:15, Daniel Fuchs wrote:
Yes - that would be simpler. Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8016344/webrev.01/
-- daniel
I agree to, this is so much simpler.
Just on the name, TestStoreToXML makes it sound
Hi,
So here is the new webrev with the test renamed...
http://cr.openjdk.java.net/~dfuchs/webrev_8016344/webrev.03/
-- daniel
On 10/18/13 3:45 PM, Alan Bateman wrote:
On 18/10/2013 14:38, Daniel Fuchs wrote:
I could remove the storeToXML subdir that I have added and rename the
new test
On 10/17/13 7:16 PM, Mandy Chung wrote:
On 10/16/13 5:35 AM, Daniel Fuchs wrote:
Hi,
Please find below the new revision:
http://cr.openjdk.java.net/~dfuchs/webrev_8026499/webrev.01/
Looks good.
As for the test, LoggingSupport.getLogger is just a layer to support the
PlatformLogger
Changeset: 567d47fd3fe2
Author:dfuchs
Date: 2013-10-21 11:15 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/567d47fd3fe2
8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7
Summary: When storing Properties to XML only locally defined properties must
Changeset: c81125493ca6
Author:dfuchs
Date: 2013-10-21 12:00 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c81125493ca6
8026499: Root Logger level can be reset unexpectedly
Summary: This fix prevents the logger's level to be re-initialized if it has
already been
Hi,
Please find below a fix for
8026863: regression in anonymous Logger.setParent method
This is a regression I introduced in JDK 8 with one of my recent
logging fixes:
8023168: Cleanup LogManager class initialization
and LogManager/LoggerContext relationship
The issue is
Hi Stuart,
This looks good to me.
RMISecurityManager:
I see that there are a few places in the JDK where we still
instantiate an RMISecurityManager.
I assume we must unfortunately keep them for backward compatibility,
in case some application code would try to downcast
Hi Joe,
I believe all the private FeatureManager could be declared
final since asfar as I can tell they are only set within
the constructor.
You could add 'final' to all declaration below:
XSLTC.java:
53 private FeatureManager _featureManager;
TransformerFactoryImpl.java:
232
,
-- daniel
On 10/22/13 5:12 PM, Mandy Chung wrote:
On 10/21/2013 2:11 PM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8026863: regression in anonymous Logger.setParent method
This is a regression I introduced in JDK 8 with one of my recent
logging fixes:
8023168: Cleanup LogManager
On 10/23/13 9:42 PM, huizhe wang wrote:
Hi Daniel,
Thanks for the review and the detailed list. I've updated the webrev:
http://cr.openjdk.java.net/~joehw/jdk8/8004476/webrev/
Looks good!
-- daniel
Thanks,
Joe
On 10/23/2013 11:25 AM, Daniel Fuchs wrote:
Hi Joe,
I believe all
Hi Mandy,
The changes look good to me - though I am a novice in this area:
so I could have missed a few things.
As a general comment I would say that this code could benefit
from some more commenting - if you don't know what it's supposed
to do then it is a bit difficult to reverse-engineer :-)
Hi Stuart,
This looks great.
Best regards
-- daniel (not a reviewer)
On 10/30/13 2:57 AM, Stuart Marks wrote:
Hi all,
Please review the following specification change to deprecate RMI/JRMP
static stubs. This change consists only of deprecations and spec
clarifications. There are no actual
of the split() method in Basic.java?
It looks as if it's not used. Is it a trap for reviewers? ;-)
best regards,
-- daniel
Mandy
On 10/29/2013 2:37 PM, Mandy Chung wrote:
On 10/29/13 2:19 PM, Daniel Fuchs wrote:
Hi Mandy,
The changes look good to me - though I am a novice in this area:
so I
Hi Jeremy,
Thanks for reporting that.
Actually I'm not quite sure that drainLoggerRefQueueBounded() needs to
be synchronized on LogManager.
I'll need to study that - but my gut feeling is that we might
be able to get rid of that lock (possibly).
I'll have to study the call chain to see whether
Changeset: d8b6af0f01f6
Author:dfuchs
Date: 2008-03-03 12:29 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d8b6af0f01f6
6651382: The Java JVM SNMP provider reports incorrect stats when asked for
multiple OIDs
Summary: The JvmMemPoolEntryImpl must use the row index when
Changeset: b64e68bf6b0b
Author:dfuchs
Date: 2008-05-29 15:33 +0200
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b64e68bf6b0b
6673853: LegacyIntrospectorTest is testing an old deprecated com.sun API not
present in OpenJDK.
Summary: Removed test from open test suite - the
Changeset: 6ca4564520e7
Author:dfuchs
Date: 2008-05-30 14:35 +0200
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6ca4564520e7
6592586: RequiredModelMBean prints a WARNING message when calling
getAttributes() for a non-existing attr
Summary: Switched traces to FINER - except when
Changeset: 233f8854d8b4
Author:dfuchs
Date: 2008-08-08 14:24 +0200
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/233f8854d8b4
6733294: MBeans tab - UI issues with writable attributes
Reviewed-by: emcmanus
! make/netbeans/jconsole/build.properties
!
Changeset: 5778303e2e14
Author:dfuchs
Date: 2008-09-09 17:01 +0200
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5778303e2e14
6745832: jmx namespaces: Some refactoring/commenting would improve code
readability.
Reviewed-by: emcmanus
!
201 - 300 of 1534 matches
Mail list logo
