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

[Kumar Srinivasan]

You are going backwards. You need to have a CSR approved first.

Kumar

> Ping. Could I please have reviews for below webrev.
>
> Thanks
> Harsha
>
> On Wednesday 14 February 2018 09:59 PM, Harsha Wardhana B wrote:
>> Hi,
>>
>> Below is the updated webrev.
>>
>> http://cr.openjdk.java.net/~hb/8187498/webrev.03/
>>
>>
>> On Wednesday 14 February 2018 01:15 AM, mandy chung wrote:
>>>
>>>
>>> On 2/13/18 1:30 AM, Harsha Wardhana B wrote:
>>>> Hi,
>>>>
>>>> Please find below the revised webrev.
>>>>
>>>> http://cr.openjdk.java.net/~hb/8187498/webrev.02/
>>>>
>>>>
>>>> On Friday 09 February 2018 05:07 AM, mandy chung wrote:
>>>>> On 2/7/18 1:19 AM, Harsha Wardhana B wrote:
>>>>> > > --start-management-agent will not be recognized in the current 
>>>>> format and
>>>>> > hence will not default to --start-management-agent=local=true.
>>>>>
>>>>> `--start-local-management-server` is one option as Alan suggests.
>>>>> Another option is to make `--start-management-agent` to accept
>>>>> an optional argument.  VM can accept `--start-management-agent`
>>>>> or `--start-management-agent=port=1234,ssl=on`.  It may require
>>>>> more launcher change to support it.
>>>> Yes. It requires lot more changes to launcher. Hence optional 
>>>> argument to --start-management-agent was not added in order to keep 
>>>> the launcher impact minimum.
>>>
>>> This is just one option for you to consider.   So the current 
>>> proposal of the new option to start a remote management server, right?
>> Not necessarily. --start-management-agent=local=true starts local 
>> server and --start-management-agent=port=1234 starts remote 
>> management server.
>>>>> Agent.java
>>>>>   If --start-management-agent is set, -Dcom.sun.management.* takes
>>>>>   precedence.  Do you really want to do that?  The new VM option
>>>>>   intends to simplify the command-line to type in.  I think it's
>>>>>   cleaner and reasonable if --start-management-agent is specified,
>>>>>   -Dcom.sun.management.* are ignored (maybe worth emit a warning 
>>>>> if set)
>>>> We can probably document that -D options will be overridden instead 
>>>> of emitting a warning.
>>>
>>> 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.
>>>
>>>>>   The implementation uses VMManagement::getVmArguments and scan
>>>>>   the VM options for -start-management-agent.  The VM is the one
>>>>>   invoking jdk.internal.agent.Agent::startAgent.  A simpler option
>>>>>   is to change Agent::startAgent to take an argument parameter
>>>>>   that will be passed with the argument of --start-management-agent
>>>>>   or null if not set.
>>>>>
>>>>>   Similarly for startRemoteManagementAgent and startLocalAgent_name.
>>>> Implementing this change requires lot of changes to argument 
>>>> parsing in native code and hence it is simpler to handle this at 
>>>> java layer.
>>>
>>> Can you describe how --start-management-agent option will be used 
>>> for jcmd and any other tool that attaches to a running VM to start 
>>> the agent?  Example command-line will be useful.
>> --start-management-agent cannot be used by jcmd (or dynamic attach) 
>> as it accepts flags only in -D format or -D flags with 
>> com.sun.management removed. That code to parse string passed via jcmd 
>> was a mistake and hence I have removed it.
>>>
>>>
>>> Mandy
>> -Harsha
>