Throwing UOE would be clearer than throwing UndeclaredThrowableException
and ReflectionException.
However MBean proxy simply forwards the call to the remote MBeanServer
and calls invoke or getAttribute/setAttribute. NoSuchMethodException
will be thrown in the remote VM and the client would get
UndeclaredThrowableException or ReflectionException. I don't see how
the client will invoke the default method unless the JMX
MBeanInvocationHandler catches the exception and have special handling
to the default methods.
Advertising
For the case of missing method in the remote VM but the client has the
default method, I got UndeclaredThrowableException. Is that what you see?
Mandy
On 8/8/17 2:22 AM, Daniel Fuchs wrote:
Hi Ujwal,
I have made a small experiments and it seems that having
a default body doesn't prevent an interface method from
being called from either a JMX or a Platform proxy.
So in the light of this I'll suggest to add a default body
that throw UnsupportedOperationException to the new methods
added to the ThreadMXBean interface, and add an @implSpec
to specify that if not implemented, the method will throw
an UnsupportedOperationException.
This should guarantee better backward compatibility in case
someone has implemented the ThreadMXBean interface.
Mandy, would you agree?
best regards
-- daniel
On 08/08/2017 09:27, Ujwal Vangapally wrote:
Hi,
below is the link to new webrev incorporating review comments.
webrev:
http://cr.openjdk.java.net/~uvangapally/webrev/2017/8185003/webrev.02/
verified that
MBeanServerConnection.invoke throws ReflectionException when invoked
with a method that doesn't exist in remote MBean server.
UndeclaredThrowableException will be throwed when a client gets proxy
of remote MBean server and calls a method that doesn't exist on
remote Mbean server.
do we need to develop Automated tests for verifying above cases ?
Thanks,
Ujwal
On 8/4/2017 5:42 AM, Mandy Chung wrote:
On Aug 3, 2017, at 2:10 PM, Daniel Fuchs <daniel.fu...@oracle.com>
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 MXBean proxies will work when proxying an interface
containing a default body. It would be interesting to check this.
ThreadMXBean is a platform MXBean and so JDK implementation is the
one implementing it. The real question here is that when
MBeanServerConnection.invoke is called on this new method that
does not exist in the remote MBeanServer (running on JDK 9 for
example), does it get javax.management.ReflectionException? Or
something else?
I believe that will be a ReflectionException:
http://download.java.net/java/jdk9/docs/api/javax/management/MBeanServerConnection.html#invoke-javax.management.ObjectName-java.lang.String-java.lang.Object:A-java.lang.String:A-
Similarly, when the client gets a proxy of ThreadMXBean from a
remote MBeanServer running on JDK 9 VM, and it calls this method,
what exception does it get? We may need to update the spec to
indicate this error cases if it’s not clear. The notes in
ManagementFactory.newPlatformMXBeanProxy covers some cases due to
the difference in the client/server are running on.
AFAIK that should be handled by the proxy code - I'd expect that you
will get an UndeclaredThrowableException wrapping the
ReflectionException.
http://hg.openjdk.java.net/jdk9/dev/jdk/file/65464a307408/src/java.management/share/classes/javax/management/MBeanServerInvocationHandler.java#l308
Thanks. That’s what I think but need assurance. We should add tests
to verify.
Mandy
