RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

[Harsha Wardhana B]

Hi All,

After internal discussions, many of the concerns below were addressed 
and final spec is published at,

https://bugs.openjdk.java.net/browse/JDK-8199584

Below is the implementation of the above spec.

http://cr.openjdk.java.net/~hb/8187498/webrev.05/

Please review and provide feedback.

Thanks
Harsha

On Wednesday 21 February 2018 08:33 PM, Roger Riggs wrote:
> Hi,
>
> I'm a bit leary of command line arguments being special cased and the 
> corresponding custom
> mappings to system properties.   The convenience is fine but we need 
> to keep the handling
> out of native code so it is easier to maintain.  We don't have a Java 
> API for processing
> (VM) command line arguments so they are being shoehorned into properties.
>
> $.02, Roger
>
> On 2/21/2018 12:55 AM, Harsha Wardhana B wrote:
>>
>>
>> On Wednesday 21 February 2018 01:51 AM, mandy chung wrote:
>>> The code review and CSR review can be in parallel.  For this case,
>>> I agree with Kumar to have CSR written that would help the code
>>> review. Please specify the behavior and its relationship with
>>> jcmd and other relevant diagnosability tools.
>> ok.
>>>
>>> On 2/20/18 6:41 AM, Kumar Srinivasan wrote:
>>>>
>>>>>>> What is the behavior when 
>>>>>>> -Dcom.sun.management.jmxremote.port=1234 
>>>>>>> --start-management-agent port=2345 
>>>>>>> -Dcom.sun.management.jmxremote.port=3456?
>>>>>>>
>>>>>>> What is the value of the system property 
>>>>>>> com.sun.management.jmxremote.port at runtime?  What port number 
>>>>>>> does the management server start with?
>>>>>> As said earlier, values set via new flags override values set by 
>>>>>> -D flags. So 2345 will be the value of 
>>>>>> com.sun.management.jmxremote.port. Added a test case to validate 
>>>>>> that.
>>>
>>> VM options are the last one wins if same option specified multiple 
>>> times.  In this case, it could cause confusion (the last -D option 
>>> sets the value to 3456 but it's set to a different value).
>>>
>>> Why not taking the simplest approach - when --start-management-agent 
>>> is set, it does not accept mixing the old way (i.e. does not accept 
>>> the management properties to be set via -D)?   This RFE is to make 
>>> the command-line simpler and ease-of-use.  I don't see any downside 
>>> to migrate entirely to the new form.
>> We cannot get rid of specifying options via -D. We have plenty of -D 
>> flags but very few have short-hand alternative via 
>> --start-management-agent. If management properties are specified by 
>> --start-management-agent, the options specified by -D are anyway 
>> overwritten if specified.
>>>
>>> Mandy
>> Harsha
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180423/065ddaed/attachment.html>