Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Harsha Wardhana B]

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 
mailto: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.


/read///

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 

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Kirk Pepperdine]

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.

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



> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B  
> 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 
>>> mailto: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.manag

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Harsha Wardhana B]

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 
mailto: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 
> 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

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Erik Gahlin]

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.


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 
mailto: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 
> wrote:


Hi Erik,


On Monday 11 September 

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Kirk Pepperdine]

Hi Harsha,


> On Sep 12, 2017, at 10:40 AM, Harsha Wardhana B 
>  wrote:
> 
> 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. 
> 

Yes, this is the precise definition that I’ve been referring to.
> 
> 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.

Indeed it cannot because they are not part of the JMXConnector API.

Ok, I reread and see I misunderstood the use cases that you’re trying to cover 
off. It seems you’re only goal is to duplicate Jolokia whereas I’m looking at a 
different use case. The primary use case I encounter is motivated by the 
inability of various sites to use JMX simply because of the operational 
restrictions that prevent them from using RMI. This JEP will help with that use 
case. That said, adding a JMXConnector with a RESTful JMXConnector would open 
up an entire JMX tool chain to them rather than have them have to define a new 
tool chain but this is outside the scope of this JEP.

> 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?

Yes, adding a JMXConnector with a RESTful JMXConnector would open up an entire 
JMX tool chain to them rather than have them have to define a new tool chain 
but this appears to be outside the scope of this JEP.

Kind regards,
Kirk

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Kirk Pepperdine]

> On Sep 12, 2017, at 12:44 PM, Erik Gahlin  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 
> 

Re: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

[Harsha Wardhana B]

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 > 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 
 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 c

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Jaroslav Tulach]

Dear reviewers,
after several reconsiderations I have webrev #4 ready for your review. Can you 
please take a look at

http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/

and let me know if it is in a reasonable shape? Thanks a lot.
-jt

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[mandy chung]

On 9/12/17 10:44 AM, Jaroslav Tulach wrote:

Dear reviewers,
after several reconsiderations I have webrev #4 ready for your review. Can you
please take a look at

http://cr.openjdk.java.net/~jtulach/8182701/webrev.04/

and let me know if it is in a reasonable shape? Thanks a lot.
-jt


Yes defining a new provider module for the platform mbean registration 
is a reasonable solution.  Generally the patch looks right.  I have a 
question on the build and a comment on the new mbean method.

./make/common/Modules.gmk
    Nit: can you move jdk.internal.vm.compiler.management to keep the 
list in alphabetical order


 199 # Filter out Graal specific modules if Graal build is disabled
 200
 201 ifeq ($(INCLUDE_GRAAL), false)
 202   MODULES_FILTER += jdk.internal.vm.compiler
 203 endif

When will INCLUDE_GRAAL be set to false?  I think 
jdk.internal.vm.compiler.management should also be filtered if 
jdk.internal.vm.compiler is disabled.


Is jdk.internal.vm.compiler and jdk.internal.vm.compiler.management 
built for all platforms in JDK 10? If not,
   jdk/src/java.management/share/classes/module-info.java may fail to 
compile when jdk.internal.vm.compiler.management is not present.   We 
can consult with the build team when you find out what configuration 
that jdk.internal.vm.compiler is not built.


hotspot/src/jdk.internal.vm.compiler/share/classes/module-info.java 29 
requires transitive jdk.internal.vm.ci;


do you get any error without this requires transitive? 
jdk.internal.vm.compiler.management already requires 
jdk.internal.vm.ci.  I would think this requires transitive is not 
necessary.


Is HotSpotGraalCompiler::mbean method necessary?  In GraalMBeans.java

  53 public static Object findGraalRuntimeBean() {
  54 JVMCIRuntime r = JVMCI.getRuntime();
  55 JVMCICompiler c = r.getCompiler();
  56 if (c instanceof HotSpotGraalCompiler) {
  57 return ((HotSpotGraalCompiler) c).mbean();
  58 }
  59 return null;
  60 }

It seems that you can call HotspotGraalRuntime::mbean directly.  As we 
discussed offline, we agree that HotSpotRuntimeMBean should belong to 
this new module but it requires some refactoring which may take some 
amount of work.  Such clean up will be followed up in a separate JBS issue.


Mandy