Changeset: 67718d2bd49c
Author:dfuchs
Date: 2008-11-14 17:22 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/67718d2bd49c
6683213: CounterMonitor's derived Gauge badly initialized
Reviewed-by: emcmanus
! src/share/classes/javax/management/monitor/CounterMonitor.java
! src/sha
Changeset: 97e2e87aa035
Author:dfuchs
Date: 2008-11-21 18:18 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/97e2e87aa035
6774170: LocalRMIServerSocketFactory should protect against
ServerSocket.accept().getInetAddress() being null
Reviewed-by: emcmanus, jfdenise
! src/share
Changeset: a99a2d2f3249
Author:dfuchs
Date: 2008-12-04 17:58 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a99a2d2f3249
6319823: new mbean register/unregister notification for groups of mbeans
6779698: Merge error caused duplicate example code in MBeanServerNotification
Revi
Changeset: 61e73bc43e72
Author:dfuchs
Date: 2008-12-09 20:20 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61e73bc43e72
6768935: Clarify the behaviour of ObjectName pattern matching with regards to
namespaces
Reviewed-by: emcmanus
! src/share/classes/com/sun/jmx/intercepto
Changeset: fa87de6b1ac3
Author:dfuchs
Date: 2009-03-12 15:36 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa87de6b1ac3
6661448: Make the SNMP agent optional when OPENJDK=true and
IMPORT_BINARY_PLUGS=false
Reviewed-by: mchung, ohair
! make/com/sun/jmx/Makefile
! make/java/
Changeset: b95c5c8ee60a
Author:jgish
Date: 2013-04-16 13:25 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/rev/b95c5c8ee60a
8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou
! make/scripts/webrev.ksh
Changeset: fad6560cb32a
Author:dfuchs
Date: 2013-04-17 15:23 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fad6560cb32a
8005954: JAXP Plugability Layer should use java.util.ServiceLoader
Summary: This fix replaces manual processing of files under META-INF/services
in JAXP
Changeset: 1c2079d11a79
Author:dfuchs
Date: 2013-04-19 17:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c2079d11a79
8010495: Update JAXP NetBeans project - add support for generating javadoc
Summary: Make it possible to use NetBeans to edit the jaxp sources and to
gene
Changeset: 2602eab5f086
Author:dfuchs
Date: 2013-05-07 11:35 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2602eab5f086
8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes
some JCK tests to fail intermittently
Summary: Encodings.java sometimes crea
Changeset: 452e1a182907
Author:dfuchs
Date: 2013-05-06 18:50 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/452e1a182907
8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes
some JCK tests to fail intermittently
Summary: Encodings.java sometimes cre
Changeset: da203779cb33
Author:jgish
Date: 2013-05-16 11:19 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da203779cb33
8013380: Removal of stack walk to find resource bundle breaks Glassfish startup
Summary: Use caller's classloader to load resource as an alternative to thre
Changeset: 6443f5627744
Author:dfuchs
Date: 2013-05-17 10:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6443f5627744
8013900: More warnings compiling jaxp.
Summary: Some internal implementation classes in Jaxp were redefining equals()
without redefining hashCode(). This
Changeset: 68209420aac2
Author:dfuchs
Date: 2013-05-17 10:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68209420aac2
8013900: More warnings compiling jaxp.
Summary: Some internal implementation classes in Jaxp were redefining equals()
without redefining hashCode(). This
Changeset: e93beba07830
Author:dfuchs
Date: 2013-06-06 20:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e93beba07830
8013434: Xalan and Xerces internal ObjectFactory need rework
Summary: With this changeset, DTMManager and XSLTCDTMManager will always use
their own defau
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 ta
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 crea
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 &
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
! test/java/util/logging/bun
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
! src/share/classes/java/util/logg
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 fix
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
! src/s
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 - Logger.ge
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: java/util/logging/Logger/getGlobal/TestGetGlobalConcur
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 t
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 for
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
! s
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 export
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
! src/s
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() =
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
! src/share/classes/sun/font/FontUtiliti
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 Logger.setResourc
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 b
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 initialized
Changeset: af4dd45bc7f7
Author:dfuchs
Date: 2013-10-28 10:52 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af4dd45bc7f7
8026863: regression in anonymous Logger.setParent method
Summary: restore behaviour of setParent in anonymous logger and clarifies the
spec with respect t
Changeset: 30a3aefc4084
Author:dfuchs
Date: 2013-11-13 10:50 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30a3aefc4084
8026952: Test
java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java has
wrong @bug id
Summary: Trivial: change @bug 8023163 into @bug
Changeset: 67d742c75971
Author:dfuchs
Date: 2013-11-19 20:10 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67d742c75971
8028185: XMLFormatter.format emits incorrect year
Summary: Fixes a regression where the year in the date was increased by 1900.
Reviewed-by: alanb, mchung
Changeset: 059530c5ae9a
Author:dfuchs
Date: 2013-11-19 22:28 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/059530c5ae9a
8005202: java/util/logging/CheckLockLocationTest.java fail on solars_10
Summary: this test has been seen failing on Solaris 10, presumably because it
was
Changeset: 9f624e115c6b
Author:dfuchs
Date: 2013-12-04 01:58 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f624e115c6b
8029281: Synchronization issues in Logger and LogManager
Summary: Fixes several race conditions in logging which have been at the root
cause of intermitte
Changeset: d77a1c9fd5b8
Author:dfuchs
Date: 2013-12-22 11:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8
8030850: Setting .level=FINEST in logging configuration file doesn't work
Summary: setLevel(INFO) was called too early on root logger, causing the value
f
On 22/04/15 04:13, Joseph D. Darcy wrote:
One goal of marking the tests using randomness is to help root out some
remaining intermittent test failures. If one of the randomness tests is
observed to fail intermittently, if it has not already been updated to
print out the random seed and be able to
is included which uses a state machine to verify that the
matching algorithm is working correctly.
Special thanks to Daniel Fuchs for contributing this fix and the test.
Thanks,
Sean
[1] http://openjdk.java.net/jeps/232
tyManager.checkPackageAcccess method. These
improvements result in a 5-7x increase in throughput of this method. A
performance chart has been attached to the bug with more information.
A new test is included which uses a state machine to verify that the
matching algorithm is working correctly.
Special thanks to Daniel Fuchs for contributing this fix and the test.
Thanks,
Sean
[1] http://openjdk.java.net/jeps/232
Changeset: 9e013ce42dd7
Author:dfuchs
Date: 2012-11-07 13:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e013ce42dd7
6720349: (ch) Channels tests depending on hosts inside Sun
Summary: This changeset make the nio tests start small TCP or UDP servers from
within the tests
Changeset: 3b6a2fe6d75c
Author:dfuchs
Date: 2012-11-28 15:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b6a2fe6d75c
8003476: Cleanup warnings in com.sun.jmx.snmp code
Reviewed-by: alanb, smarks
! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
! src/share/classes/
Hi Max,
These tests are whitebox tests - the tests classes are patched
into the java.net.http module, and as a consequence they can't
compile against library classes which are on the classpath.
This is the unfortunate reason for the presence of a
SimpleSSLContext clone in there.
best regards,
-
On 08/11/2018 15:03, Sean Mullan wrote:
Ah, I see. I am sure there is a good reason, but why doesn't it have an
implementation?
IIRC there was an implementation in the deploy code.
best regards,
-- daniel
Hi Claes,
It might read even better if things like:
+resultString = !specarg.isEmpty() ? specarg.intern(): opt;
were changed into:
+resultString = specarg.isEmpty() ? opt : specarg.intern();
best regards,
-- daniel
On 12/12/2018 16:53, Claes Redestad wrote:
Hi,
please revi
, Daniel Fuchs wrote:
Hi Claes,
It might read even better if things like:
+ resultString = !specarg.isEmpty() ? specarg.intern(): opt;
were changed into:
+ resultString = specarg.isEmpty() ? opt : specarg.intern();
best regards,
I only found this pattern in this file, so incremental
Hi Xuelei,
On 22/12/2018 17:20, Xue-Lei Fan wrote:
The issue is caused by the handshake status "NEED_WRAP" while the
connection is half-closed. An application may just call wrap() when the
handshake status is "NEED_WRAP". For compatibility, I changed the
handshake status from NEED_WRAP back to
Hi Xuelei,
This is not my area of expertise - so I'm going to rephrase
what I understand (which may be wrong):
SSLEngineImpl.java:
This change makes sure that the SSLEngineResult::getStatus()
returns Status.CLOSED when closure has been initiated, even
if the engine is only half-closed at t
Hi Jay,
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04. The issue was with the
half closed semantics of the SSL engine in TLS 1.3.
best regards,
-- daniel
On 08/02/2019 21:43, Jay Modi wrote:
Hi,
I've been doing some testing with Apache HttpClient again
Looks good to me Xuelei!
Thanks for taking this on.
best regards,
-- daniel
On 01/03/2019 16:54, Xuelei Fan wrote:
Hi Daniel,
Could I have a review of the following update:
http://cr.openjdk.java.net/~xuelei/8219990/webrev.00/
The update in the previous fix:
http://cr.openjdk.java.n
/019100.html
http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019142.html
Hope this help,
-- daniel
On 06/03/2019 09:55, Severin Gehwolf wrote:
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04
Hi Norman,
On 13/03/2019 12:54, Norman Maurer wrote:
Wasn’t it possible at some point to browse the bugs without a login ? When I
try to look at the issue it asks me for a login :/
Sorry about that.
You should be able to find all the information about the
issue in the public review thread in
Looks good to me Chris!
cheers,
-- daniel
On 13/03/2019 17:04, Chris Hegarty wrote:
Trivially, there should be a comma after the year. Just add it.
Hi Xuelei,
I second Alan's suggestion to use VarHandle CAS for getDefault().
Otherwise you will have a race between getDefault() and setDefault()
which will be problematic (and could make tests/app fail randomly).
WRT default factories I like the new holder class.
I wonder if you should bite the
Hi Xuelei,
Looks good to me.
SSLContext.java
72 throw new InternalError(e);
Why not `new ExceptionInInitializerError(e)` ?
SSLSocketImpl.java:
In `duplexCloseOutput()` I wonder if you should nest two
`try { } finally { }` statements to make really sure that the lock
is actually
Hi Xuelei,
I believe there is still a small window of opportunity
for which `readLockedDeplete();` will never be called.
The issue is in `deplete()`:
If tryLock() fails to lock at line
1046 if (readLock.tryLock()) {
then there's no guarantee that the reading
thread will not release
ill update if there is a
surprise in the regression testing.
Thanks,
Xuelei
On 5/3/2019 4:11 AM, Daniel Fuchs wrote:
Hi Xuelei,
I believe there is still a small window of opportunity
for which `readLockedDeplete();` will never be called.
The issue is in `deplete()`:
If tryLock() fails to lo
Hi Xuelei,
looks good to me as well.
best regards,
-- daniel
On 05/05/2019 16:18, Xuelei Fan wrote:
All good catches!
I made the update accordingly. Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8219991/webrev.03/
Thanks,
Xuelei
On 5/3/2019 11:27 PM, Alan Bateman wrote:
O
Hi Valery,
On 11/05/2019 00:36, Valerie Peng wrote:
http://cr.openjdk.java.net/~valeriep/7107615/webrev.02/
Please let me know if you have more comments.
If I'm not mistaken, the only thing that references
the IdentityWrapper is the key in the WeakHashMap.
Therefore, it is only weakly referen
Hi Valerie,
This looks good to me.
I just wonder why IdentityWrapper has a parameter type as it
seems it's only used with T = Provider.
I mean - this is fine - and I understand why you did it this way
as the general purpose parameterized class is much easier to name,
but I wonder if you wouldn't
Hi Arthur,
On 17/05/2019 00:16, Arthur Eubanks wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8224081
webrev: http://cr.openjdk.java.net/~aeubanks/8224081/webrev.00/index.html
Tests that try to use SOCKS v4 will fail in an IPv6 only environment
since SOCKS v4 does not support IPv6. SOCKS
Hi Severin,
Here is an example of a manual test checked in in the jdk repo:
http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/sun/security/provider/PolicyParser/ExtDirs.java
- it has an @test annotation
- it has an @bug annotation
- it has an @run main/manual line
- it has a comment explaini
On 17/05/19 17:58, Severin Gehwolf wrote:
Thanks! How about this?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203190/03/webrev/
Yes, the test looks good to me!
Thanks Severin,
best regards,
-- daniel
Hi Arthur, [adding security-dev]
18 // For IPSupport
19 grant {
20 permission java.net.SocketPermission "localhost:0",
"listen,resolve";
21 permission java.util.PropertyPermission
"java.net.preferIPv4Stack", "read";
22 };
It might be better if these permissions were granted
Looks good to me Valerie!
Best regards,
-- daniel
On 22/05/2019 18:30, Valerie Peng wrote:
Updated per Daniel's feedback on IdentityWrapper:
http://cr.openjdk.java.net/~valeriep/7107615/webrev.04/
Mach5 run is clean.
Thanks,
Valerie
Hi Arthur,
On 22/05/2019 18:28, Arthur Eubanks wrote:
New webrev: http://cr.openjdk.java.net/~aeubanks/8224256/webrev.01/
Looks good to me - please just get someone from security-dev
to review too.
best regards,
-- daniel
Hi,
Please find a patch below that temporarily problem lists
java/security/SecureClassLoader/DefineClass.java
on linux and windows until JDK-8224635 [1] is fixed:
8224656: Problem list java/security/SecureClassLoader/DefineClass.java
until JDK-8224635 is fixed
https://bugs.openjdk.java.
Hi,
I have observed an intermittent failure on Solaris.
So I changed the patch to problem-list the test on all platform.
Is that still OK?
http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01
best regards,
-- daniel
On 23/05/2019 10:32, Daniel Fuchs wrote:
Hi,
Please find a patch
Hi Xuelei,
I am not an expert of the field so please get another
reviewer for this change:
656 if (!super.isOutputShutdown() &&
...
661 } else if (!super.isOutputShutdown()) {
I think it might be clearer with a nested if:
if
On 13/06/19 20:59, Xuelei Fan wrote:
Hi Daniel,
All good points. Here is the update webrev:
http://cr.openjdk.java.net/~xuelei/8224829/webrev.01/
Thanks,
Xuelei
Looks good to me Xuelei!
best regards,
-- daniel
Hi Vladimir,
On 20/06/2019 02:03, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8185139/webrev.00/
Ah - I see that the logging test are the principal offenders here.
Sorry about that ;-(
I looked at the various logging tests and the proposed changes look
good to me. Thanks for updati
Hi Alan,
On 20/06/2019 16:36, Alan Bateman wrote:
I think that's right. In the case of the j.u.logging tests then maybe
SimplePolicy could be factored out into a separate source file so there
aren't 20 or so tests with a SimplePolicy and implies method that checks
the default policy.
I don't
Hi Sean,
On 20/06/2019 21:40, Sean Mullan wrote:
This could also be fixed in these tests by inspecting the CodeSource of
the ProtectionDomain. Or better yet, they should just use the jtreg
java.security.policy option and a policy file and avoid the need to
create a Policy implementation.
In
Hi Sean,
On 21/06/2019 15:36, Sean Mullan wrote:
Ok, I see that is challenging, and I understand why you had to do that.
You probably could have done something similar by breaking up the test
into multiple classes in separate directories (or jars) with different
ProtectionDomains, but that wou
Hi Claes,
I wonder if initialize() should check the state of
the readOnly() flag - and if that's true, call
perms.setReadOnly() ?
see SecureClassLoader::getProtectionDomain(..)
best regards,
-- daniel
On 15/08/2019 13:44, Claes Redestad wrote:
Hi,
On 2019-08-15 12:56, Alan Bateman wrote:
O
Thanks Claes,
Looks good to me too.
best regards,
-- daniel
On 15/08/2019 16:27, Roger Riggs wrote:
Looks good,
Thanks, Roger
On 8/15/19 11:22 AM, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8
Hi,
(cc-ing security dev for the changes in
test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java
which is updated to allow for binding on a specific
IP Address)
Please find below a patch for:
8230435: Replace wildcard address with loopback or local host
in tests - part 22
https://
Thanks Michael!
If I don't receive more comments I will be pushing this
shortly...
best regards,
-- daniel
On 03/09/2019 14:53, Michael McMahon wrote:
Looks fine to me Daniel.
- Michael.
On 02/09/2019, 14:00, Daniel Fuchs wrote:
Hi,
(cc-ing security dev for the changes in
test/jdk/
On 13/01/2020 10:28, Seán Coffey wrote:
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place, the
EventHelper utility class should never initialize the logging framework
early during jar initialization.
http://cr.openjdk
On 13/01/2020 14:06, Chris Hegarty wrote:
I’m going to ask, since I cannot find the answer myself. Why are some
securityLogger::log invocations guarded with isLoggingSecurity, and others not?
With this change shouldn’t all invocations be guarded, since it is
isLoggingSecurity that assigns secu
On 13/01/2020 17:21, Chris Hegarty wrote:
On 13 Jan 2020, at 17:19, Seán Coffey wrote:
Thanks for the reviews. All callers of EventHelper log methods are ensuring
that isLoggingSecurity() is true before proceeding. I've added an assert null
check in the 4 logger methods to ensure expectations
Hi John,
Looks good to me. Thanks for taking care of this!
I'm glad to see the binary files go away :-)
Would it be possible to include a comment in Cert.java that contains
the command you used to generate the certificates?
That will be a great help to future maintainers if the certificates
eve
Hi Prasad,
On 07/02/2020 14:28, Prasadrao Koppula wrote:
Thanks for review Sean, I will add test changes.
Not a review - but I just wanted to double check that
you have run the :jdk_net tests too - especially the
httpclient tests (which are part of :jdk_net) as the
httpclient is a heavy user o
On 08/02/2020 07:46, sha.ji...@oracle.com wrote:
Hi Daniel,
I'll do that.
Please review this updated webrev:
http://cr.openjdk.java.net/~jjiang/8238677/webrev.01/
The script, exactly gen-certs.sh, can be used to generate the certs.
Looks good to me John!
best regards,
-- daniel
Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses double locking?
It will avoid synchronizing in the happy case where `hasKeyAttributes`
has already been computed.
1924 private boolean hasKeyAttributes() {
1925
Hi Valerie,
Please ignore my comment. Sorry for the noise.
I somehow clicked on the wrong webrev link :-(
best regards,
-- daniel
On 12/03/2020 11:35, Daniel Fuchs wrote:
Hi Valerie,
Given that hasKeyAttributes is already decelared as volatile,
may I suggest the following change that uses
Hi Xuelei,
HandshakeCompletedEvent.java: typo:
186 "This method has retired, pleaase use the " +
Same in SSLSession.java:
303 "This method has retired, pleaase use the " +
WRT to the HttpClient code I wonder whether the deprecated method
should be kept. On the on
Hi Pavel,
On 08/04/2020 13:56, David Holmes wrote:
and `@exception` tags for checked exceptions that were neither thrown
nor imported
Hopefully that's only on internal classes.
It might be prudent to separate this out in a different
changeset. It's not always obvious where an exception
is thro
On 08/04/2020 12:50, Pavel Rappo wrote:
Vipin, here you go:
https://bugs.openjdk.java.net/browse/JDK-8242366
http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
Hi Pavel,
That looks good to me.
WRT to the @exception changes I'll leave that responsibility
to Sean ;-)
best regards,
Good work Rahul!
I am not sure whether that deserves a CSR (probably not) but we may
want to create some release note to explain that the HttpClient is no
longer overriding the default protocols selected by the SSLContext.
So HTTP 1.1 over TLSv1.1 might now get negotiated where previously
an han
Thanks Rahul. I believe you can mark it as Delivered now.
On 09/04/2020 14:13, Rahul wrote:
Thanks for the review Daniel.
I have created a release note.
RN :https://bugs.openjdk.java.net/browse/JDK-8242387
Hi Alexey,
This is not a review. A few high level comments however:
For that kind of change that introduce a new environment
property you will need to file a CSR, and probably provide
some release notes as well.
Your changes seem to trigger new IllegalStateException and
UnsupportedOperationExce
Hi Alexey,
Could we move the new code from LdapClient.java and LdapCtxt.java
into the com.sun.jndi.ldap.sasl package, and possibly delay
its execution until the com.sun.jndi.ldap.sasl.LdapSasl.saslBind
method is called?
The new TlsChannelBinding class should also be preferably moved
to com.sun.j
Hi Alexey,
On 05/06/2020 17:33, Alexey Bakhtin wrote:
Hi Daniel,
Thank you for review
Yes, I can move TlsChannelBinding class into the com.sun.jndi.ldap.sasl package
and LdapClient related changes into the LdapSasl.saslBind method.
Also, you are right with exceptions. I will rename them to the
On 09/06/2020 23:21, Sean Mullan wrote:
The issue is not observed with java-14, thus I assume that the fix is
related to commit
http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4
As java-11 is LTS, what is the procedure to get it fix back-ported?
Hi,
AFAICS the fix has already been backpor
Hi Alexey,
This is starting to look good.
Thank you for persisting!
I have a couple of comments - on the LDAP/JNDI side.
There are several places where your new code is supposed to
trigger the throwing of a NamingException:
LdapSasl.java: lines 76, 85, 140, 168
Please write a test to verify
Hi Alexey,
The JNDI/LDAP part looks mostly good. You will need someone
from the security libs to review the security lib part of the
changes.
In the test I would recommend using the test URIBuilder to avoid
strange intermittent errors if the test is run on a
machine where looking up "localhost"
Hi Michael,
On 30/06/2020 15:57, Osipov, Michael wrote:
TLS channel binding is not tied to LDAP, it can be used with other
protocols, even custom ones. I see no good reason to have the property
contain jndi.ldap or use NamingException. IllegalArgumentException would
be approriate here
It is no
1 - 100 of 308 matches
Mail list logo
