JDK-8171311 Current state

[Erik Gahlin]

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