Hi Kirk,
REST APIs work as an adapter and cannot work as a connector. To quote
from the JEP,
The REST adapter is a part of the Distributed services level.
Connectors mirror the interfaces of agent level services to remote
clients, whereas adapters transform agent level services to different
protocol. The proposed functionality will transform Agent level
services to REST APIs, hence the name "REST adapter".
A connector *must* adhere to the JMX remoting spec. REST APIs cannot
adhere to that because they expose APIs via HTTP and not Java. Hence it
is called an Adapter and not a connector. It can never work as a
'drop-in' replacement for JMX/RMI Connector. Existing tools using using
RMIConnector will have to be modified to use REST APIs.
The current JEP does not allow all of the CRUD operations on MBeans. In
the spirit of keeping the APIs language agnostic, only read/write is
supported. It is not possible to specify create/delete REST APIs for JMX
without incorporating language specific features. I would welcome
discussions around including create/delete APIs for MBeans.
In lieu of the above, as of now REST adapter cannot exist independently
and will have to live along-side RMIConnector.
-Harsha
On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote:
Hi Harsha,
The only reason I mentioned Jolokia is that it’s a project that
usefulness is some what limited because it is *not* a compliment JMX
connector and as such cannot be used as a straight drop-in replacement
for the current RMI based connector. Is your plan here to make it a
fully compliant connector so that we could configure tooling such as
the MBean viewers in jConsole and VisualVM (or JMC for that matter) to
use a restful connector instead of an RMI based connector? IMHO, doing
so would represent a huge win as I know of quite a few projects that
cannot or will not use JMX because of it’s reliance on RMI.
Consolidating all of the options under a single flag looks like
another interesting win.
Kind regards,
Kirk
On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B
<[email protected] <mailto:[email protected]>>
wrote:
Hi Erik,
On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote:
Hi Harsha,
I haven't looked at Jolokia, or know what is the most reasonable
approach in this case, but as a principle, I think we should strive
for the best possible design rather than trying to be compatible
with third party tools.
Agreed. That will always be the first priority. That is the reason
HTTP GET interfaces will not be changed. I am undecided if the POST
payloads need to be changed (without compromising the REST design
principles) to increase adoption of this feature.
How will the command line look like to start the agent with the rest
adapter?
In the past there have been discussions about adding syntactic sugar
for -Dcom.sun.management, i.e.
-Xmanagement:ssl=false,port=7091,authenticate=false
instead of
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=7091
-Dcom.sun.management.jmxremote.authenticate=false
which is hard to remember, cumbersome to write and error prone since
the parameters are not validated. If we are adding support for REST,
it could perhaps be default, i.e.
-Xmanagement:ssl=false,authenticate=false,port=80
If you want to use JMX over RMI you would specify protocol:
-Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi
Yes. There is an enhancement request to add the -Xmanagemet:*
syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST
adapter will use one of the above flags though I haven't thought of
the exact name for it yet. I will update the JEP with the details of
the flag shortly.
Has there been any thoughts about JMX notifications?
Notifications will not be supported in this JEP.
* MBean Notifications are not a widely used feature and will not be
supported via the REST adapter.
I know it is outside the scope of the JEP, but I think we should
take it into consideration when doing the design, so the
functionality could be added on later without too much difficulty.
Notifications can be added without modifying the current design too
much. If required, it will be worked upon via an enhancement request.
Thanks
Erik
Thanks
Harsha
Hi Martin,
In my opinion, the interfaces exposed by current JEP are lot closer
to REST style than the interfaces exposed by Jolokia.
For instance, HTTP GET by default should be used to read resources,
but it is made part of URL in Jolokia interfaces.
<base-url>/read/<mbean name>/<attribute name>/<inner path>
I would wait on opinions from more people before considering
changing the current interfaces.
Thanks
-Harsha
On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote:
Hello
Would one at least consider adopting the same URL paths and
payloads as Jolokia? This could make life a lot easier for third
party tools that connect to it.
Best Regards
Martin Skarsaune
ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B
<[email protected] <mailto:[email protected]>>:
Hi Kirk,
Yes. Jolokia was considered and is listed as an alternative in
the JEP.
* Jolokia can serve as a viable alternative but can be
bulky. We are looking for simple and lightweight solution.
-Harsha
On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote:
Hi,
Have you run into this project?https://jolokia.org <https://jolokia.org/>.
Unfortunately it’s not exactly a drop in replacement for the standard RMI based JMX
connector but it’s not far off.
Kind regards,
Kirk
On Sep 5, 2017, at 6:30 PM, Erik Gahlin<[email protected]>
<mailto:[email protected]> wrote:
Hi Harsha,
Looping in jmx-dev.
byte[], short[], int[], float[], double[]
Should long[] be included there as well?
The REST adapter will come with a simple and lightweight JSON parser.
Is this an internal parser or will it be exposed as an API?
If so, how does it relate to JEP 198: Light-Weight JSON API?
http://openjdk.java.net/jeps/198
Will com.sun.net.httpserver.HttpServer be used to serve the requests?
Thanks
Erik
Hi All,
Please review the JEP for REST APIs for JMX :
https://bugs.openjdk.java.net/browse/JDK-8171311
The JEP aims at providing RESTful web interfaces to MBeans.
Access to MBeans registered in a MBeanServer running inside a JVM requires
a Java client. Language-agnostic access to MBeans will require spawning a Java
client which can be cumbersome. The proposed JEP allows MBeans to be accessed
in a language/platform-independent, ubiquitous and seamless manner.
Thanks
-Harsha
