Hi Kirk,Erik,
The current JEP addresses the first use-case. Second use case can be
realized by adding a JMXConnector that operates over REST APIs provided
by the current JEP. But that is outside the scope of this JEP.
-Harsha
On Tuesday 12 September 2017 04:27 PM, Kirk Pepperdine wrote:
On Sep 12, 2017, at 12:44 PM, Erik Gahlin <erik.gah...@oracle.com
<mailto:erik.gah...@oracle.com>> wrote:
I guess there are two use cases:
1) Simple interoperability with other languages.
2) A drop in replacement for RMI
Can a JMX connector be written that support both use cases? I don't
know, but if not it could be that we need both a connector and an
adapter.
I think if you were to extend JMXConnector to wrap the REST API you
might be able to expose both. But I’m not sure it would be a great
solution. I think a second JEP would be a better option.
— Kirk
Erik
Hi Kirk,
I guess the term 'connector' here is loosely applied. When I say
connector, I mean the connector that provides implementation of the
package below,
https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html
RMIConnector is one implementation of above connector.
On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote:
Hi Harsha,
From Chapter 5 of the JMX documentation. "Many different
implementations of connectors are possible. In particular, there
are many possibilities for the protocol used to communicate over a
connection between client and server.”
It goes on in the Generic Connector section under "User-Defined
Protocols” to say; "While the RMI connector must be present in
every implementation of the JMX Remote API, you can also implement
a connector based on a protocol that is not defined in the JMX
Remote API standard. A typical example of this is a connector based
on a protocol that uses HTTP/S. Other protocols are also possible.
The JMX specification describes how to implement a connector based
on a user-defined protocol.”
Unless I’m missing something, this all suggests that there is
nothing inherently wrong is using REST behind a JMXConnector.
I hope above should clarify what I refer to when I say JMXConnector.
In that sense, REST APIs alone cannot work as connector. In fact, it
stands parallel to connector, as in it directly wraps the
MBeanServer and does not wrap any JMXConnector. The JEP has detailed
information about where the REST adapter sits in the JMX architecture.
Are you suggesting that we implement a JMXConnector that works over
REST?
As written this JEP pretty much looks like Jolokia. Jolokia is a
great project and as such I fail to see the benefits of simply
duplicating it. I’d also argue that the usefulness of that project
has been some what muted because it is not a drop in replacement
for the standard RMI connector meaning that one has to modify an
entire tool chain just to make use of it. However, creating a REST
based JMXConnector would be immediately useful.
As an aside, Jus last week I started on a JMXConnector that uses a
shared memory segment for communications. Of course this
implementation would only be available for local communications but
it offers some advantages over using a socket based protocol, even
if that comms is over local loopback.
Kind regards,
Kirk Pepperdine
Thanks
Harsha
On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B
<harsha.wardhan...@oracle.com> wrote:
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
<harsha.wardhan...@oracle.com> 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
<harsha.wardhan...@oracle.com>:
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<erik.gah...@oracle.com>
<mailto:erik.gah...@oracle.com> 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
