[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX
From: Harsha Wardhana B <harsha.wardhana.b () oracle ! com>
Date: 2017-09-12 14:28:15
Message-ID: c1211e98-1590-7a8f-920d-cca09dc4a071 () oracle ! com
[Download RAW message or body]
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.gahlin@oracle.com
> > <mailto:erik.gahlin@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.wardhana.b@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.wardhana.b@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.wardhana.b@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.gahlin@oracle.com> \
> > > > > > > > > > > > <mailto:erik.gahlin@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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Kirk,Erik,</p>
<p>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.</p>
<p>-Harsha<br>
</p>
<br>
<div class="moz-cite-prefix">On Tuesday 12 September 2017 04:27 PM,
Kirk Pepperdine wrote:<br>
</div>
<blockquote type="cite"
cite="mid:010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Sep 12, 2017, at 12:44 PM, Erik Gahlin <<a
href="mailto:erik.gahlin@oracle.com" class=""
moz-do-not-send="true">erik.gahlin@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">I guess there are two use
cases:<br class="">
<br class="">
1) Simple interoperability with other languages.<br
class="">
2) A drop in replacement for RMI<br class="">
<br class="">
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.<br class="">
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
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.</div>
<div><br class="">
</div>
<div>— Kirk</div>
<div> <br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix"> <br class="">
Erik<br class="">
<br class="">
</div>
<blockquote
cite="mid:9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com"
type="cite" class="">
<meta http-equiv="Context-Type" content="text/html;
charset=utf-8" class="">
<p class="">Hi Kirk,</p>
<p class="">I guess the term 'connector' here is loosely
applied. When I say connector, I mean the connector
that provides implementation of the package below,</p>
<p class=""><a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summar \
y.html">https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html</a></p>
<p class="">RMIConnector is one implementation of above
connector. <br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On Tuesday 12 September
2017 12:56 PM, Kirk Pepperdine wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:F1731B46-B45B-42A4-AA25-E87EA91AAD4D@gmail.com"
class=""> Hi Harsha,
<div class="">
<div class=""><br class="">
</div>
<div class="">From Chapter 5 of the JMX
documentation. "<span class="">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."</span></div>
<div class="">
<div class=""><br class="">
</div>
<div class="">It goes on in the Generic Connector
section under "User-Defined Protocols" to say; "<span
class="">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.</span>"</div>
<div class=""><span class=""><br class="">
</span></div>
<div class="">Unless I'm missing something, this
all suggests that there is nothing inherently
wrong is using REST behind a JMXConnector.</div>
</div>
</div>
</blockquote>
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. <br class="">
<br class="">
Are you suggesting that we implement a JMXConnector that
works over REST?<br class="">
<blockquote type="cite"
cite="mid:F1731B46-B45B-42A4-AA25-E87EA91AAD4D@gmail.com"
class="">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:F1731B46-B45B-42A4-AA25-E87EA91AAD4D@gmail.com"
class="">
<div class="">
<div class="">
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Kind regards,</div>
<div class="">Kirk Pepperdine</div>
</div>
</div>
</blockquote>
<br class="">
Thanks<br class="">
Harsha<br class="">
<blockquote type="cite"
cite="mid:F1731B46-B45B-42A4-AA25-E87EA91AAD4D@gmail.com"
class="">
<div class="">
<div class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">On Sep 12, 2017, at 9:04 AM,
Harsha Wardhana B <<a
class="moz-txt-link-abbreviated"
href="mailto:harsha.wardhana.b@oracle.com"
\
moz-do-not-send="true">harsha.wardhana.b@oracle.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<p class="">Hi Kirk,</p>
<p class="">REST APIs work as an adapter
and cannot work as a connector. To quote
from the JEP,</p>
<div class=""> <br
class="webkit-block-placeholder">
</div>
<blockquote type="cite" class=""><span
class="">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".</span></blockquote>
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. <br class="">
<div class=""><br
class="webkit-block-placeholder">
</div>
<p class="">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. <br class="">
</p>
<p class="">In lieu of the above, as of
now REST adapter cannot exist
independently and will have to live
along-side RMIConnector. <br class="">
</p>
<p class="">-Harsha<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On Monday 11
September 2017 09:05 PM, Kirk Pepperdine
wrote:<br class="">
</div>
<blockquote type="cite"
\
cite="mid:61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com" class=""> Hi Harsha,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Consolidating all of the
options under a single flag looks like
another interesting win.</div>
<div class=""><br class="">
</div>
<div class="">Kind regards,</div>
<div class="">Kirk</div>
<div class=""><br class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Sep 11, 2017,
at 4:08 PM, Harsha Wardhana B
<<a
class="moz-txt-link-abbreviated"
href="mailto:harsha.wardhana.b@oracle.com" \
moz-do-not-send="true">harsha.wardhana.b@oracle.com</a>> wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<div class="">
<p class="">Hi Erik,<br
class="">
</p>
<br class="">
<div class="moz-cite-prefix">On
Monday 11 September 2017
07:14 PM, Erik Gahlin
wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">Hi
Harsha,<br class="">
<br class="">
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.<br
class="">
</div>
</blockquote>
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. <br
class="">
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">
<br class="">
How will the command
line look like to start
the agent with the rest
adapter?<br class="">
<br class="">
In the past there have
been discussions about
adding syntactic sugar
for
-Dcom.sun.management,
i.e.<br class="">
<br class="">
-Xmanagement:ssl=false,port=7091,authenticate=false<br class="">
<br class="">
instead of<br class="">
<br class="">
-Dcom.sun.management.jmxremote.ssl=false <br class="">
-Dcom.sun.management.jmxremote.port=7091<br class="">
-Dcom.sun.management.jmxremote.authenticate=false <br class="">
<br class="">
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.<br
class="">
<br class="">
-Xmanagement:ssl=false,authenticate=false,port=80<br class="">
<br class="">
If you want to use JMX
over RMI you would
specify protocol:<br
class="">
<br class="">
-Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi<br
class="">
</div>
</blockquote>
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.
<br class="">
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">
<br class="">
Has there been any
thoughts about JMX
notifications?<br
class="">
</div>
</blockquote>
Notifications will not be
supported in this JEP. <br
class="">
<ul class="">
<li class="">MBean
Notifications are not a
widely used feature and
will not be supported
via the REST adapter.</li>
</ul>
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">
<br class="">
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.<br
class="">
</div>
</blockquote>
Notifications can be added
without modifying the
current design too much. If
required, it will be worked
upon via an enhancement
request. <br class="">
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">
<br class="">
Thanks<br class="">
Erik<br class="">
<br class="">
</div>
</blockquote>
Thanks<br class="">
Harsha<br class="">
<blockquote type="cite"
cite="mid:59B69336.7070200@oracle.com"
class="">
<div
class="moz-cite-prefix">
</div>
<blockquote
\
cite="mid:b3f6547b-438e-3bda-1109-d8e35bbebcb1@oracle.com" type="cite" class="">
<p class="">Hi Martin,</p>
<p class="">In my
opinion, the
interfaces exposed by
current JEP are lot
closer to REST style
than the interfaces
exposed by Jolokia. <br
class="">
</p>
<p class="">For
instance, HTTP GET by
default should be used
to read resources, but
it is made part of URL
in Jolokia interfaces.</p>
<pre \
class="synopsis"><base-url>/read/<mbean name>/<attribute \
name>/<inner path></pre> <br class="">
I would wait on opinions
from more people before
considering changing the
current interfaces.<br
class="">
<br class="">
Thanks<br class="">
-Harsha<br class="">
<br class="">
<div
class="moz-cite-prefix">On
Wednesday 06 September
2017 11:40 AM, Martin
Skarsaune wrote:<br
class="">
</div>
<blockquote type="cite"
cite="mid:CA+QL28WYtZdppsSw64zzYo2-_xOsO9tXij+tntygcJPw3vRPjg@mail.gmail.com"
class="">
<div dir="ltr"
class="">Hello
<div class=""><br
class="">
</div>
<div class="">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. </div>
<div class=""><br
class="">
</div>
<div class="">Best
Regards</div>
<div class=""><br
class="">
</div>
<div class="">Martin
Skarsaune </div>
</div>
<br class="">
<div
class="gmail_quote">
<div dir="ltr"
class="">ons. 6.
sep. 2017 kl.
07:04 skrev Harsha
Wardhana B <<a
class="moz-txt-link-abbreviated"
\
href="mailto:harsha.wardhana.b@oracle.com" \
moz-do-not-send="true">harsha.wardhana.b@oracle.com</a>>:<br class=""> </div>
<blockquote
class="gmail_quote">
<div class=""> Hi
Kirk,<br
class="">
<br class="">
Yes. Jolokia was
considered and
is listed as an
alternative in
the JEP.<br
class="">
<br class="">
<ul class="">
<li class="">Jolokia
can serve as a
viable
alternative
but can be
bulky. We are
looking for
simple and
lightweight
solution.</li>
</ul>
<br class="">
-Harsha<br
class="">
<br
\
class="m_-2330093802961999704Apple-interchange-newline"> <div
\
class="m_-2330093802961999704moz-cite-prefix">On Wednesday 06
September 2017
10:21 AM, Kirk
Pepperdine
wrote:<br
class="">
</div>
<blockquote
type="cite"
class="">
<pre class="">Hi,
Have you run into this project? <a \
class="m_-2330093802961999704moz-txt-link-freetext" href="https://jolokia.org/" \
target="_blank" moz-do-not-send="true">https://jolokia.org</a>. 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
</pre>
</blockquote>
</div>
<div class="">
<blockquote
type="cite"
class="">
<blockquote
type="cite"
class="">
<pre class="">On Sep 5, \
2017, at 6:30 PM, Erik Gahlin <a class="m_-2330093802961999704moz-txt-link-rfc2396E" \
href="mailto:erik.gahlin@oracle.com" target="_blank" \
moz-do-not-send="true"><erik.gahlin@oracle.com></a> wrote:
Hi Harsha,
Looping in jmx-dev.
</pre>
<blockquote
type="cite"
class="">
<pre class="">byte[], \
short[], int[], float[], double[] </pre>
</blockquote>
<pre class="">Should long[] \
be included there as well?
</pre>
<blockquote
type="cite"
class="">
<pre class="">The REST \
adapter will come with a simple and lightweight JSON parser. </pre>
</blockquote>
<pre class="">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?
<a class="m_-2330093802961999704moz-txt-link-freetext" \
href="http://openjdk.java.net/jeps/198" target="_blank" \
moz-do-not-send="true">http://openjdk.java.net/jeps/198</a>
Will com.sun.net.httpserver.HttpServer be used to serve the requests?
Thanks
Erik
</pre>
<blockquote
type="cite"
class="">
<pre class="">Hi All,
Please review the JEP for REST APIs for JMX :
<a class="m_-2330093802961999704moz-txt-link-freetext" \
href="https://bugs.openjdk.java.net/browse/JDK-8171311" target="_blank" \
moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8171311</a>
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
</pre>
</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br class="">
</blockquote>
<br class="">
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br class="">
</blockquote>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic