Re: JDK-8171311 Current state
The reason to put this into the JDK is to standardize the protocol. If you want to build a client today, you must build one for every adapter because they have different ways to represent URLs etc. The JDK is in unique position to set the standard, since the implementation comes by default. Erik Thanks, I just found that JEP searching for an simple way to attach to a non application server VM avoiding the hassle for setting up Firewall Rules for RMI and that JEP was the first in the list followed by the Jolokia that seems not jet ready for Java 11... I will look into the Jolokia library and will try to find out, what the exact issues with Java 11 are. Besides that it would really make sense to see if there would be a better way for starting the JMX services as Alan pointed out. -Patrick On 2018-12-07 10:59, Raghavan Puranam wrote: My apologies Patrick...I should have added the comment first before closing. I have added it now. Regards, Raga -Original Message- From: Alan Bateman Sent: Friday, December 7, 2018 2:52 PM To: Patrick Reinhart Cc: serviceability-dev@openjdk.java.net Subject: Re: JDK-8171311 Current state On 07/12/2018 08:36, Patrick Reinhart wrote: It's a bit disturbing that just at the time of my question this JEP has been closed (without any further comment why) I suspect your inquiry prompted Raghavan to close it as there isn't (to my knowledge anyway) anyone actively working on it. I agree a comment is needed when closing issues. I think that it still would be worth while looking into supporting a REST based implementation in favour of the existing RMI based solution just by the fact of the troubles just one can have with firewalls. Right, and I think there is some interest. In addition to the REST adapters that you found then I think some of the app servers have support too. The big question for features like this is whether it is something that the JDK has to include or not (the batteries included vs. batteries available discussion). If you look at Harsha's prototype (linked from the JEP) then you'll you see it can be mostly developed in its own project, the only JDK piece is integrating it with the JMX agent and existing -Dcom.sun.management options for starting the JMX agent. I think this is an area that could be improved to make it easier to deploy JMX adapters that aren't in the JDK. -Alan
Re: JDK-8171311 Current state
Thanks, I just found that JEP searching for an simple way to attach to a non application server VM avoiding the hassle for setting up Firewall Rules for RMI and that JEP was the first in the list followed by the Jolokia that seems not jet ready for Java 11... I will look into the Jolokia library and will try to find out, what the exact issues with Java 11 are. Besides that it would really make sense to see if there would be a better way for starting the JMX services as Alan pointed out. -Patrick On 2018-12-07 10:59, Raghavan Puranam wrote: My apologies Patrick...I should have added the comment first before closing. I have added it now. Regards, Raga -Original Message- From: Alan Bateman Sent: Friday, December 7, 2018 2:52 PM To: Patrick Reinhart Cc: serviceability-dev@openjdk.java.net Subject: Re: JDK-8171311 Current state On 07/12/2018 08:36, Patrick Reinhart wrote: It's a bit disturbing that just at the time of my question this JEP has been closed (without any further comment why) I suspect your inquiry prompted Raghavan to close it as there isn't (to my knowledge anyway) anyone actively working on it. I agree a comment is needed when closing issues. I think that it still would be worth while looking into supporting a REST based implementation in favour of the existing RMI based solution just by the fact of the troubles just one can have with firewalls. Right, and I think there is some interest. In addition to the REST adapters that you found then I think some of the app servers have support too. The big question for features like this is whether it is something that the JDK has to include or not (the batteries included vs. batteries available discussion). If you look at Harsha's prototype (linked from the JEP) then you'll you see it can be mostly developed in its own project, the only JDK piece is integrating it with the JMX agent and existing -Dcom.sun.management options for starting the JMX agent. I think this is an area that could be improved to make it easier to deploy JMX adapters that aren't in the JDK. -Alan
RE: JDK-8171311 Current state
My apologies Patrick...I should have added the comment first before closing. I have added it now. Regards, Raga -Original Message- From: Alan Bateman Sent: Friday, December 7, 2018 2:52 PM To: Patrick Reinhart Cc: serviceability-dev@openjdk.java.net Subject: Re: JDK-8171311 Current state On 07/12/2018 08:36, Patrick Reinhart wrote: > It's a bit disturbing that just at the time of my question this JEP > has been closed (without any further comment why) I suspect your inquiry prompted Raghavan to close it as there isn't (to my knowledge anyway) anyone actively working on it. I agree a comment is needed when closing issues. > > I think that it still would be worth while looking into supporting > a REST based implementation in favour of the existing RMI based > solution just by the fact of the troubles just one can have with > firewalls. Right, and I think there is some interest. In addition to the REST adapters that you found then I think some of the app servers have support too. The big question for features like this is whether it is something that the JDK has to include or not (the batteries included vs. batteries available discussion). If you look at Harsha's prototype (linked from the JEP) then you'll you see it can be mostly developed in its own project, the only JDK piece is integrating it with the JMX agent and existing -Dcom.sun.management options for starting the JMX agent. I think this is an area that could be improved to make it easier to deploy JMX adapters that aren't in the JDK. -Alan
Re: JDK-8171311 Current state
On 07/12/2018 08:36, Patrick Reinhart wrote: It's a bit disturbing that just at the time of my question this JEP has been closed (without any further comment why) I suspect your inquiry prompted Raghavan to close it as there isn't (to my knowledge anyway) anyone actively working on it. I agree a comment is needed when closing issues. I think that it still would be worth while looking into supporting a REST based implementation in favour of the existing RMI based solution just by the fact of the troubles just one can have with firewalls. Right, and I think there is some interest. In addition to the REST adapters that you found then I think some of the app servers have support too. The big question for features like this is whether it is something that the JDK has to include or not (the batteries included vs. batteries available discussion). If you look at Harsha's prototype (linked from the JEP) then you'll you see it can be mostly developed in its own project, the only JDK piece is integrating it with the JMX agent and existing -Dcom.sun.management options for starting the JMX agent. I think this is an area that could be improved to make it easier to deploy JMX adapters that aren't in the JDK. -Alan
Re: JDK-8171311 Current state
It's a bit disturbing that just at the time of my question this JEP has been closed (without any further comment why) I think that it still would be worth while looking into supporting a REST based implementation in favour of the existing RMI based solution just by the fact of the troubles just one can have with firewalls. When doing a quick search for JMX REST adapters, I did not found that many: - Jolokia (seems to be active) [1] - Apache ESME - JMX REST API (inactive) [2] - MX4J (inactive) [3] - OpenDMK (not found anymore) -Patrick I'm not aware of any current activity on this in OpenJDK. One thing about the JEP is that it didn't make the case clear as to why the adapter needed to be in the JDK. There are also several existing JMX adapters that support REST and it would have been useful to evaluate those and maybe explore what the pain points and issues are with deploying these solutions. It might be that the -Dcom.sun.management mechanism to start the JMX agent needs to be improved, maybe it should be integrated with -javaagent, maybe the pluggability of the JMX agent just needs to be improved. -Alan [1] https://jolokia.org/features-nb.html [2] https://esme.apache.org/docs/apis/jmx-rest-api.html [3] http://mx4j.sourceforge.net
Re: JDK-8171311 Current state
On 06/12/2018 07:58, Patrick Reinhart wrote: Hi everybody, I am already done some contributions within the core libs of the JDK and wanted to ask if I could help in bringing this JEP forward. Looking into the it the last actions where made mid year- Is there any work being done here in the mean time? I'm not aware of any current activity on this in OpenJDK. One thing about the JEP is that it didn't make the case clear as to why the adapter needed to be in the JDK. There are also several existing JMX adapters that support REST and it would have been useful to evaluate those and maybe explore what the pain points and issues are with deploying these solutions. It might be that the -Dcom.sun.management mechanism to start the JMX agent needs to be improved, maybe it should be integrated with -javaagent, maybe the pluggability of the JMX agent just needs to be improved. -Alan
JDK-8171311 Current state
Hi everybody, I am already done some contributions within the core libs of the JDK and wanted to ask if I could help in bringing this JEP forward. Looking into the it the last actions where made mid year- Is there any work being done here in the mean time? -Patrick
