Hi Felix,
On 11/01/2020 07:37, Yangfei (Felix) wrote:
Hi Daniel,
Thanks for the suggestions.
I modified the patch making the third port also configurable via the
management.properties file.
New webrev: http://cr.openjdk.java.net/~fyang/8234484/webrev.01/
I think I would prefer
Hi Daniil,
Looks good to me as well. I wonder however if the release note
should point to the replacement?
Something like:
The terminally deprecated constant
`javax.management.remote.rmi.RMIConnectorServer.CREDENTIAL_TYPE` has
been removed. A filter pattern can be specified instead using
`RMI
Hi Daniil,
That looks fine to me.
best regards,
-- daniel
On 15/01/2020 18:15, Daniil Titov wrote:
Please review a change [1] that fixes a deadlock issue [2] in
sun.tools.jconsole.Worker class.
There is no need in guarding "stopped" flag by a lock. The fix removes this
excessive locking an
Thanks Felix!
On 16/01/2020 02:01, Yangfei (Felix) wrote:
Modified accordingly in new webrev:http://cr.openjdk.java.net/~fyang/8234484/webrev.02/
Also renamed property to: com.sun.management.jmxremote.local.port
That looks fine to me.
best regards,
-- daniel
Hi Roger,
I think you will need to preserve these cases:
On 13/02/2020 15:52, Roger Riggs wrote:
- || valObj instanceof Long
- || valObj instanceof Integer
- || valObj instanceof Float
- || valObj instanceof Double
- ||
Hi Roger,
OK - I can accept that then.
best regards,
-- daniel
On 13/02/2020 18:18, Roger Riggs wrote:
Hi Daniel,
That's part of the technical debt that has to go.
The change to do the conversion in the constructor has been there since
JDK8.
And the value of the argument is informative.
Hi Alexander,
Fixes to JMX & management agent are reviewed on the
seviceability-dev (added in to:) these days.
best regards,
-- daniel
On 05/03/2020 13:17, Alexander Scherbatiy wrote:
Hello,
Could you review a small enhancement where the test CustomLauncherTest
is updated to build binary la
Hi Milan,
JMX is being maintained by serviceability these days.
I am forwarding your question there.
This is an interesting observation. JMX makes it possible to
define and use annotations on methods/getters/setters, to add
key/value pairs to the Descriptor of the corresponding
MBeanFeatureInfo.
Hi David,
Good finding! Looks reasonable to me.
best regards,
-- daniel
On 15/10/2018 05:23, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8048215
webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/
Simple race condition in the test. The main thread does checks th
Hi Mandy,
This looks good to me.
best regards,
-- daniel
On 15/10/2018 23:02, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/
This simple patch fixes the issue Sven reports [1] where
the order of names and values when creating CompositeData
for
Hi Mandy,
I agree that this looks more robust and will be better for
long term maintainability. I'm just surprised that
156 static CompositeType compositeType() {
157 return STACK_TRACE_ELEMENT_COMPOSITE_TYPE;
158 }
is no longer (or was never) needed in StackTraceElementCompo
Hi Paul,
On 12/02/2019 16:27, Hohensee, Paul wrote:
I don't see a way to change the Status from Closed to anything else. There's no
option I can find to do so.
It may be that only the assignee can see this.
On the closed CSRs assigned to me I can see a "Back to Draft" button
next to "More".
Hi Severin,
Did you manage to make the test pass locally?
This test has had a long history of failing, and I've come
to suspect that it might be flawed.
First - it has /timeout=5. I believe that's much too short.
It immediately failed the first time I ran it locally on my machine.
Then it uses
Hi Severin,
Thanks for looking into this!
On 25/02/2019 15:31, Severin Gehwolf wrote:
Hi Daniel,
Thanks for the review!
Latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/02/webrev/
On Fri, 2019-02-22 at 18:31 +, Daniel Fuchs wrote:
Hi Severin,
Did you manage to
Hi Severin,
On 25/02/2019 15:31, Severin Gehwolf wrote:
Hi Daniel,
Thanks for the review!
Latest webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/02/webrev/
[...]
I'm not sure we need a larger timeout. It's 20 seconds on my machine
which seems more than enough. What makes yo
On 26/02/2019 18:58, Severin Gehwolf wrote:
FWIW, I use 'make test TEST="..."'. Isn't the testing system using that
too?
I am not sure. But I'd expect it to be similar.
[...]
When I was working on that patch years ago, I think one testing machine
got configured in a way so that it wouldn't t
Hi Severin,
On 27/02/2019 16:26, Daniel Fuchs wrote:
On Mac OS X and Linux - I saw it failed too - though with lower
frequency (like 3 or 4 times every 100 runs), and AFAICS
usually later and for a different reason: when it fails, it usually
timeouts when trying to test over SSL.
On Solaris
Hi Severin,
On 28/02/2019 15:47, Severin Gehwolf wrote:
Yes, thanks for looking at this Daniel. That was my determination as
well. However, even if we do all of the above, and add a test config
with /etc/hosts mapping a non-loopback address to "localhost" it would
break other tests. E.g. this on
Hi Severin,
On 01/03/2019 15:49, Severin Gehwolf wrote:
On Fri, 2019-03-01 at 15:08 +, Daniel Fuchs wrote:
I ran it 50 times in our test system - and it passed on all platforms,
so there's yet hope :-)
Thanks for this! I take it, it actually runs the test on some of those
test sy
-- daniel
I'll run this through jdk/submit now. Could you run this through your
test system too, please?
Would you be OK with getting this patch pushed once we'd have positive
results for both?
Thanks,
Severin
On Fri, 2019-03-01 at 15:08 +, Daniel Fuchs wrote:
Hi Severin,
O
On 12/03/2019 14:24, Gary Adams wrote:
Need one reviewer for this trivial correction .
Having had to do the same for java.logging, I can say that the
doc changes to package-info.java look good to me :-)
AFAICT the changes to the copyright notice look OK too.
best regards,
-- daniel
After
Hi Severin,
On 08/03/2019 13:20, Severin Gehwolf wrote:
On Fri, 2019-03-08 at 11:59 +, Daniel Fuchs wrote:
- please verify on your local box if testing both plain &
SSL with a Thread.sleep(1000) in between makes the test
more stable. If it does, then I'd prefer we go down
18:22, Daniel Fuchs wrote:
This is what I have tried:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8219585/04/webrev/
If you think we should try this one. That's fine with me.
I have now also tested webrev.04 with a test config that uses
the fastdebug VM and observed many intermi
Hi Arthur,
Not directly related to Alex's original question but...
On 30/03/2019 00:03, Arthur Eubanks wrote:
We have some ipv6 patches as well in this area as well (as well as other
patches to support ipv6 only environments) that we're trying to
upstream. I don't understand the code myself, b
Hi Ao Qi,
I'm adding serviceability-dev, since this is for jdwp.
The proposed changes look good to me - but please get
someone from the serviceability team to review this.
best regards,
-- daniel
On 16/05/2019 08:41, Ao Qi wrote:
Hi,
I found build is failed on CentOS 7.6, because of loop i
Hi,
On 20/05/2019 01:43, David Holmes wrote:
Webrev: http://cr.openjdk.java.net/~dtitov/8214545
Bug: https://bugs.openjdk.java.net/browse/JDK-8214545
The count-- is obvious as it is the loop counter, but it is far from
clear to me that i++ is correct. I don't fully understand the logic but
i i
On 21/05/2019 04:25, Daniil Titov wrote:
Please review un updated version of the previous change that also removes
unnecessary line
chmod ug+x $REVOKEALL
from test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh
Webrev:http://cr.openjdk.java.net/~dtitov/8214545/webrev.03
Hi Paul,
It might be worth double checking what happens if you create a
MXBean proxy to access the com.sun.management.ThreadMXBean
in a remote server:
https://download.java.net/java/early_access/jdk14/docs/api/java.management/java/lang/management/ManagementFactory.html#getPlatformMXBean(javax.ma
Hi,
On 21/09/2019 00:28, Hohensee, Paul wrote:
java.lang.management.ThreadMXBean has two default methods that throw
UnsupportedOperationException:
ThreadInfo[] getThreadInfo(long[], boolean, boolean, int)
ThreadInfo[] dumpAllThreads(boolean, boolean, int)
Without actually testing it, is it sa
Hi Ujwal,
For consistency I think the new getListenerIds method should:
a) either return an array of Integer, even if it contains only 1
Integer:
1. The name of the method implies that an array is returned
2. You will need the array when you call
connection.removeNotificationListeners
/jdk9/docs/api/javax/management/remote/rmi/RMIConnection.html#removeNotificationListeners-javax.management.ObjectName-java.lang.Integer:A-javax.security.auth.Subject-
Thanks,
Ujwal
On 5/8/2017 12:03 PM, Daniel Fuchs wrote:
Hi Ujwal,
For consistency I think the new getListenerIds method should:
lly have a strong opinion on this and am okay with either names.
-Harsha
On Monday 08 May 2017 03:16 PM, Daniel Fuchs wrote:
On 08/05/2017 09:45, Ujwal Vangapally wrote:
Thanks for the Review Daniel, Harsha
Please find the new webrev incorporating the review comments
webrev :
http://cr.openjdk.j
+1
Thanks Ujwal!
-- daniel
On 09/05/17 06:38, Ujwal Vangapally wrote:
Hi Harsha, Daniel,
updated method names as getListenerIds/getListenerId
webrev :
http://cr.openjdk.java.net/~uvangapally/webrev/2017/6515161/webrev.02/
On 5/8/2017 9:57 PM, Daniel Fuchs wrote:
Hi Harsha,
Well, I
Hi Amit,
Can you point to the changeset (or the reason) which caused
the exception to change?
I'd like to make sure we don't have some regression lurking
here...
best regards,
-- daniel
On 16/05/2017 09:45, Amit Sapre wrote:
Hello,
Please review this trivial fix to StartManagementAgent tes
Hi,
If I'm not mistaken then this will make it impossible
for earlier release to interoperate with newer releases
as the LocalRMIClientSocketFactory class will not be
present the client tries to deserialize the stub.
best regards,
-- daniel
On 19/06/2017 11:52, Ujwal Vangapally wrote:
Hi,
Ki
ter for
out-of-jvm clients.
I don't see how introducing this fix can cause new interoperability
problems. Can you please elaborate?
-Harsha
On Monday 19 June 2017 10:23 PM, Daniel Fuchs wrote:
Hi,
If I'm not mistaken then this will make it impossible
for earlier release to interop
Thanks,
Ujwal.
On 6/20/2017 2:40 PM, Daniel Fuchs wrote:
Hi Harsha,
Maybe I'm missing something.
How is the local agent started?
If it's started when you connect jconsole to a process
by specifying the process ID - then I suspect this will
prevent e.g. jconsole or jvisualvm
The fix looks good to me Harsha.
best regards,
-- daniel
On 20/06/2017 07:10, Harsha Wardhana B wrote:
Hi,
Please review the below RFE,
JDK-8182485 : JMX connections should have configurable ObjectInputFilter
having webrev at
http://cr.openjdk.java.net/~hb/8182485/webrev.00/
The enhanceme
Hi Mandy,
On 03/08/17 21:04, Mandy Chung wrote:
Adding a public method to an interface is an incompatible source
change unless there is a default body. On the other hand I am not sure
how MXBean proxies will work when proxying an interface containing a
default body. It would be interesting to
Thanks,
Ujwal
On 8/4/2017 5:42 AM, Mandy Chung wrote:
On Aug 3, 2017, at 2:10 PM, Daniel Fuchs
wrote:
Hi Mandy,
On 03/08/17 21:04, Mandy Chung wrote:
Adding a public method to an interface is an incompatible source
change unless there is a default body. On the other hand I am not
sure how
y(connection, name, I.class).m() is actually what
is returned by M.m(), not what is returned by I.m().
This means that you can evolve MBean interfaces by adding methods
to them as long as you provide a default body (which is rather cool :-))
best regards,
-- daniel
Mandy
On 8/8/17 2:22 AM, Dan
Hi Ujwal,
The java part looks good to me.
ThreadMXBean.java:
775 * @implSpec if not implemented, the method will throw
776 * an UnsupportedOperationException.
and
862 * @implSpec if not implemented, the method will throw
863 * an UnsupportedOperationException.
I wonde
Hi Jaroslav,
GraalMBeans.java:
77 @Override
78 public Set mbeanInterfaceNames() {
79 return Collections.singleton(name);
80 }
This is not correct. The return set should be a set of
MXBean interface names, as in Class.getName(), not a set
of MXBean Obj
Hi Harsha,
Good work!
> http://cr.openjdk.java.net/~hb/5016517/webrev.03/
long standing typo in management.properties at line 90:
measureRole => monitorRole
HashedPasswordManager.java: loadPasswords()
It seems this function will add the header to the file even
if it already contains the he
09/10/2017 06:34, Harsha Wardhana B wrote:
Hi Daniel,
Below is the webrev addressing the review comments.
http://cr.openjdk.java.net/~hb/5016517/webrev.04/
On Friday 06 October 2017 03:38 PM, Daniel Fuchs wrote:
Hi Harsha,
Good work!
> http://cr.openjdk.java.net/~hb/5016517/webrev.03/
l
Hi Shafi,
If I compare your webrev [1] with the JDK 9 changeset [2] then this
looks OK to me.
best regards,
-- daniel
[1] http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/
[2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/9c9b8a48cd4a
On 25/10/2017 09:11, Shafi Ahmad wrote:
Hi,
On 31/10/2017 17:07, mandy chung wrote:
On 10/31/17 8:55 AM, Harsha Wardhana B wrote:
Hi Mandy,
Below is the new webrev incorporating below review comments.
http://cr.openjdk.java.net/~hb/5016517/webrev.06/
Looks okay in general except this:
286 // Check if header needs to be ins
e webrev addressing Daniel and Mandy's comments.
http://cr.openjdk.java.net/~hb/5016517/webrev.07/
-Harsha
On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote:
On 31/10/2017 17:07, mandy chung wrote:
On 10/31/17 8:55 AM, Harsha Wardhana B wrote:
Hi Mandy,
Below is the new webrev
Hi Ujwal,
Give that there are only 4 legal values to check then maybe
you could check all of them in the test (and not simply 2).
best regards,
-- daniel
On 08/11/2017 18:34, Ujwal Vangapally wrote:
Thanks for the suggestions Roger, Mandy.
below is webrev incorporating review comments.
htt
On 09/11/2017 10:40, Ujwal Vangapally wrote:
Thanks for the Review Daniel, made changes as suggested.
webrev :
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/
Looks good to me.
-- daniel
Ujwal.
Hi Harsha,
On 10/11/2017 12:38, Harsha Wardhana B wrote:
Hi,
Please find the below webrev with the following changes.
1. All the reads/writes into the password file are synchronized w.r.t
threads within the JVM and across multiple JVM processes. It is possible
that some edits made to file wh
Hi Ujwal,
Still looks good to me.
best regards,
-- daniel
On 15/11/2017 13:18, Ujwal Vangapally wrote:
kindly review the updated webrev including changes to
MBeanInfoHashCodeNPETest.java
webrev :
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.05/
Thanks,
Ujwal.
On
Hi Harsha,
Looks good.
nit:
366 if(random.nextBoolean()) {
367 String[] tokens = line.split("\\s+");
368 if ((tokens.length == 4 || tokens.length == 3)) {
inverting the two if () (testing for the applicability of the line
first) would
+1
-- daniel
On 05/12/2017 12:04, Harsha Wardhana B wrote:
Hi Daniel,
On Tuesday 05 December 2017 03:42 PM, Daniel Fuchs wrote:
Hi Harsha,
Looks good.
Thanks for the review.
nit:
366 if(random.nextBoolean()) {
367 String[] tokens = line.split(&quo
Hi Jeremy,
I'm not sure I understand exactly what is going on there.
I wonder if this has anything to do with an issue I noticed some
time back when the jvisualvm for JDK 8 and JDK 9 were still out
of sync:
https://bugs.openjdk.java.net/browse/JDK-8167099
I stumbled on that because at the time I
Hi Mandy,
Nice to see this fixed.
In ThreadInfoCompositeData::initV6CompositeType
425 if (name.equals(STACK_TRACE)) {
426 ot = new ArrayType<>(1,
StackTraceElementCompositeData.v5CompositeType());
427 } else if (name.equals(LO
Hi Mandy,
This looks very good.
In the API documentation of ThreadInfo::from, below the table
that lists the attributes of StackTraceElement, I wonder if the
following text should be added for completeness:
```A CompositeData representing a MonitorInfo of version N must contain
a lockedStackTr
avoid the ambiguity.
* The {@code "lockedStackFrame"} attribute in
* {@link MonitorInfo#from(CompositeData) MonitorInfo}'s composite type
* must represent {@code StackTraceElement} of the same version N.
Looks fine!
-- daniel
Mandy
On 2/28/18 3:07 AM, Dan
[ccing serviceability-dev@openjdk.java.net]
Hi Siba,
This looks good to me - but I'm not a SSL expert.
It would be good to get someone from the security team eyeball those
changes (Xuelei? Brad?)
I added serviceability-dev@openjdk.java.net in cc as this is where
reviews for JMX/Monitoring chang
Hi Harsha,
On a high level point of view, I think the fix looks good.
I like the use of CopyOnWriteArrayList and removeIf.
IIUC there is a single instance of ServiceThread in the VM, so
using a static single thread executor to call the listeners
should preserve the order in which the notification
Hi Harsha,
On 23/08/2018 17:35, Daniel Fuchs wrote:
So all in all - maybe this is worth fixing but better early
in the release than late. I also wonder whether such a behavior
change should deserve a release note (or a switch to revert
to the old behavior - though I do hope that isn't nece
efully
leave time enough for the while loop to take two histograms. Simply
adding the extra condition to keep looping until we have at least two
should do the trick.
best regards, and thanks again for taking care of 6977426!
-- daniel
// Katja
On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
Hi Katja
enough
even for slower configurations.
Good suggestion. I should have thought of that :-)
The new webrev can be found here:
http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/
Thumbs up from me!
cheers,
-- daniel
// Katja
On 12/17/2014 12:33 PM, Daniel Fuchs wrote:
On 17/12/14 12
On 13/01/15 10:28, shanliang wrote:
Hi
Please review this test bug fix
Bug: https://bugs.openjdk.java.net/browse/JDK-8068774
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/
Looks good Shanliang!
best regards,
-- daniel
The problem must be here:
98 monitorProxy.start();
99
100
Hi Shanliang,
This looks good.
ManagementFactory.java:
line 871: there's a stray debug trace that you probably
forgot to remove:
871 System.out.println("\n\n= jsl adding: "+provider);
lines 877-885:
I believe it would improved readability if the content of the
forEachOrd
On 28/01/15 07:46, Mandy Chung wrote:
com/sun/management/internal/PlatformMBeanProviderImpl.java
line 43: does this mxbeanList have to be created lazily?
Would it be better to make it a final field and create it at the
constructor?
Hi Mandy,
I was the one to suggest the lazy initializa
Hi Jaroslav,
The only thread state that this test is waiting on seems to be
Thread.State.BLOCKED - which makes me wonder if you could add a
method:
String waitForBlockedState(Thread t) throws InterruptedException {
long tid = lt.getId();
ThreadInfo ti;
while ( (ti = mbean.getThreadInf
On 29/01/15 16:21, Jaroslav Bachorik wrote:
On 29.1.2015 14:58, Daniel Fuchs wrote:
Hi Jaroslav,
The only thread state that this test is waiting on seems to be
Thread.State.BLOCKED - which makes me wonder if you could add a
method:
String waitForBlockedState(Thread t) throws
y to defer
loading providers and may be better to follow up the performance side
in the second phase (that I expect more changes to sun/management
classes)
You may want to consider using limited doPrivileged (that can be done
in the second phase).
OK, now they are final, I will add doPrivileged
On 30/01/15 20:05, Jaroslav Bachorik wrote:
On 30.1.2015 19:52, Daniel Fuchs wrote:
Hi Jaroslav,
On 30/01/15 19:40, Jaroslav Bachorik wrote:
Hi,
On 30.1.2015 18:38, shanliang wrote:
Hi,
Thanks for all your comments, here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK
Looks good to me Shanliang.
-- daniel
On 03/02/15 14:16, shanliang wrote:
Hi,
Hope this is last time :)
http://cr.openjdk.java.net/~sjiang/JDK-8065213/02/
1)
Mandy Chung wrote:
You may want to consider using limited doPrivileged (that can be done
in the second phase).
Done as in Managem
Looks good to me too.
JEP 102 Process Updates will provide an easier way to get the
current process PID but we don't have that yet :-)
best regards,
-- daniel
On 11/02/15 17:42, Yekaterina Kantserova wrote:
Hi,
Could I please have a review of this small fix.
bug: https://bugs.openjdk.java.n
Looks good Mandy!
-- daniel
On 19/02/15 20:01, Mandy Chung wrote:
This removes the SNMP messages from the sun.management.resources.agent
resource bundle:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8062750/webrev.00/
thanks
Mandy
Looks good to me too Shanliang.
-- daniel
On 04/03/15 19:41, Jaroslav Bachorik wrote:
Hi Shanliang,
This looks fine.
I have few minor nits:
* ClientNotifForwarder.java#544 - Should read "Received" instead of
"Receives"
* copyright year updates to both of files
No need to re-review.
-JB-
O
Hi Jaroslav,
Looks reasonable to me. Not sure why you replaced Barrier with
Semaphore but I don't really mind.
best regards,
-- daniel
On 06/03/15 17:08, Jaroslav Bachorik wrote:
Please, review the following test change
Issue : https://bugs.openjdk.java.net/browse/JDK-671
Webrev: http://
Hi Shanliang,
Impressive work! I know how long it took you and how much
effort went into this!
This does look good.
One minor remark is that it might have been good to have a simple
mechanical rule to transform the name of the MBean concrete
implementation from the java.management module to the
Hi Jaroslav,
Shouldn't you also wait for the blockedThread to be blocked on
lockA at around line 252?
(I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
best regards,
-- daniel
On 4/13/15 10:07 AM, Jaroslav Bachorik wrote:
On 9.4.2015 20:11, Jaroslav Bachorik wrote:
Plea
On 14/04/15 11:28, Jaroslav Bachorik wrote:
Hi Daniel,
On 14.4.2015 09:38, Daniel Fuchs wrote:
Hi Jaroslav,
Shouldn't you also wait for the blockedThread to be blocked on
lockA at around line 252?
(I mean - using Utils.waitForThreadState(blockedThread, State.BLOCKED))
Yes, nice
Hi Jaroslav,
I like this change, but it does introduce an incompatibility,
so it probably needs a CCC and some release notes.
For instance, this test passes with the current version of
ObjectName:
public class StringLengthTest {
final static int smax = Short.MAX_VALUE;
final static int
On 14/04/15 14:56, Daniel Fuchs wrote:
With that in mind I believe you should consider throwing
InternalError - or IllegalArgumentException - instead of
using 'assert' statements.
Actually - MalformedObjectNameException would be more appropriate.
Stupid me.
-- daniel
Hi Joe,
Looks good to me!
+1 for doclint :-)
best regards,
-- daniel
On 4/16/15 4:47 AM, joe darcy wrote:
Hello,
While trying to turn on doclint checking in the build on more modules,
it came to my attention that various parts of the javax.management
package are missing javadoc. Please re
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
On 19/05/15 15:39, Jaroslav Bachorik wrote:
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8080663
Webrev: http://cr.openjdk.java.net/~jbachorik/8080663/webrev.00
The title says it all. This enhancement is about replacing the arbitrary
reflection based code
Hi Jaroslav,
I haven't looked at the code, but if I understand well,
that would be a spec change.
Attribute names are case sensitive in JMX.
getFoo() => attribute named "Foo"
getfoo() => attribute named "foo"
Are you proposing to change that?
best regards,
-- daniel
On 18/06/15 18:39, Jar
On 6/18/15 7:16 PM, Jaroslav Bachorik wrote:
On 18.6.2015 18:47, Daniel Fuchs wrote:
Hi Jaroslav,
I haven't looked at the code, but if I understand well,
that would be a spec change.
Attribute names are case sensitive in JMX.
getFoo() => attribute named "Foo"
getfoo() =
Hi guys,
I believe there's a difference between Attribute names, and navigation
into complex attributes.
At the MBean level attribute names are case sensitive.
At Attribute level (= within an attribute) I believe it follows
the Bean patterns (like for instance the mapping of complex
MXBean attri
Hi Iris,
This looks reasonable to me.
best regards,
-- daniel
On 21/07/15 07:30, Iris Clark wrote:
Hi.
Please review changes to resolve the following bug:
8132003: Update javax/management regression test for Verona (versioning)
Bug: https://bugs.openjdk.java.net/browse/JDK-8132003
The regr
, Jaroslav Bachorik wrote:
On 19.6.2015 18:20, Jaroslav Bachorik wrote:
On 19.6.2015 15:50, Daniel Fuchs wrote:
Hi guys,
I believe there's a difference between Attribute names, and navigation
into complex attributes.
At the MBean level attribute names are case sensitive.
At Attribute l
roslav Bachorik wrote:
On 14.4.2015 14:56, Daniel Fuchs wrote:
Hi Jaroslav, I like this change, but it does introduce an
incompatibility, so it probably needs a CCC and some release notes.
For instance, this test passes with the current version of
ObjectName: public class StringLengthTest {
Jaroslav Bachorik
:
Eamonn, Daniel,
thanks for the comments.
I've updated the webrev to address them. Also, I've added a test to
exercise
the boolean flag en-/decoding in ObjectName.
http://cr.openjdk.java.net/~jbachorik/8041565/webrev.03
Cheers,
-JB-
On 4.8.2015 23:02, Daniel
Hi Jaroslav,
I'll look at the code in more details, but doesn't your
webrev miss some modifications to modules.xml?
oh - I see you have module-info.java - are you planning to
push that in jake repo first then?
best regards,
-- daniel
On 08/10/15 13:49, Jaroslav Bachorik wrote:
Please, review
Hi Jaroslav,
1. I think it would be good to change the synopsis of the issue
to match what the proposed change does.
It seems to me that something like:
Add a new javax.management.annotation.ConstructorProperties
annotation
would be a better description.
2. I agree with Alan th
On 09/10/15 14:30, Jaroslav Bachorik wrote:
Would it be possible for javac to recognise a class is an MXBean and
turn-on -parameters for such classes only by default? Too hacky?
Definitely :) Hacky as heck :)
I agree with Jaroslav.
FWIW - The @CP is not used for the MXBean itself, but for th
Hi Jaroslav,
This looks good to me. I wonder if @bug 7199353 should be added
to some of the existing tests too, given that you modified them
to use the new annotation.
best regards,
-- daniel
On 14/10/15 11:36, Jaroslav Bachorik wrote:
On 8.10.2015 13:49, Jaroslav Bachorik wrote:
Please, rev
Hi Jaroslav,
This - and the cleanup - look good to me, but it would
be nicer if it was accompanied by a unit test :-)
best regards,
-- daniel
On 19/10/15 13:37, Jaroslav Bachorik wrote:
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8139870
Webrev: http:
On 19/10/15 15:36, Jaroslav Bachorik wrote:
On 19.10.2015 14:40, Daniel Fuchs wrote:
Hi Jaroslav,
This - and the cleanup - look good to me, but it would
be nicer if it was accompanied by a unit test :-)
This time with test -
http://cr.openjdk.java.net/~jbachorik/8139870/webrev.01
Thanks
On 10/20/15 10:00 AM, Jaroslav Bachorik wrote:
Ran JCK, just to be sure. It did pass, as expected (I am changing the
internal sun.management implementation and not a Java SE API, afterall).
Thanks Jaroslav!
Looks good to me then :-)
-- daniel
Hi Severin,
Adding serviceability-dev@openjdk.java.net into the loop - that's
a better alias than hotspot-dev for this kind of changes - maybe
someone from serviceability-dev will offer to sponsor :-)
I will let serviceability team members comment on the hotspot changes.
ConnectorBootstrap.java
Hi Alexander,
This looks a bit dangerous to me - it could create a busy loop
if for some reason the connection can never go through.
I would suggest retrying only once (or retrying a fixed number
of times) - and possibly introducing a small delay (Thread.sleep)
before retrying.
best regards,
-
Hi Alexander,
Looks good to me :-)
I like the:
System.out.println("Connection error. Retrying after delay...");
which will help diagnose if something more serious is causing
this failure: if we see 100th of them then I guess it will mean that the
test needs further debugging to get at the conn
1 - 100 of 380 matches
Mail list logo
