On Fri, 15 Oct 2021 10:58:29 GMT, Denghui Dong <dd...@openjdk.org> wrote:

>> (RFC: 
>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2021-October/039796.html)
>> 
>> I proposed to extend DCmd to allow Java developers to customize their own 
>> diagnostic commands last week.
>> 
>> At present, I have implemented a preliminary version.
>> 
>> In the current implementation, I provided some simple APIs in the Java layer 
>> (under sun.management.cmd) for defining and registering commands.
>> 
>> - Executable interface
>>   Java diagnostic commands need to implement this interface, the interface 
>> only contains a simple method:
>> 
>>     /**
>>      * @param output the output when this executable is running
>>      */
>>     void execute(PrintWriter output);
>> 
>> 
>> - Add two annotations (@Command and @Parameter) to describe the command meta 
>> info
>> 
>> - Use Factory API to register command, the following forms are supported
>> 
>> @Command(name = "My.Echo", description = "Echo description")
>> class Echo implements Executable {
>> 
>>     @Parameter(name = "text", ordinal=0, isMandatory = true)
>>     String text;
>> 
>>     @Parameter(name = "repeat", isMandatory = true, defaultValue = "1")
>>     int repeat;
>> 
>>     @Override
>>     public void execute(PrintWriter out) {
>>         for (int i = 0 ; i < repeat; i++) {
>>             out.println(text);
>>         }
>>     }
>> }
>> 
>> Factory.register(Echo.class);
>> 
>> 
>> 
>> Factory.register("My.Date", output -> {
>>     output.println(new Date());
>> });
>> 
>> 
>> - When the command is running, the VM will call `Executor.executeCommand` to 
>> execute the command. In the implementation of Executor, I introduced a 
>> simple timeout mechanism to prevent the command channel from being blocked.
>> 
>> At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd 
>> and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, 
>> help, etc.).
>> 
>> In terms of security, considering that the SecurityManager will be 
>> deprecated, there are not too many considerations for the time being.
>> 
>> Any input is appreciated.
>> 
>> Thanks,
>> Denghui
>
> Denghui Dong has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   print argument key if not found

Thanks for the commands, the following is my thought.

Compared with the user's own implementation of a DiagnosticCommandMBean, the 
main benefits of this extension are:

Users can directly use `jcmd` to invoke (better user experience, of course, 
users can also invoke through a jmx client like jconsole), and use `jcmd pid 
help` to list all VM commands and user-defined commands. And all parameters or 
options are pre-parsed, making the implementation of the command simpler and 
focusing on their own logic. 

I am not an expert in the security field, but I feel that implementing a 
DiagnosticCommandMBean by the users does not seem to be more secure than the 
method in the proposal. I mean the users can still do whatever they want.

Just like Chris said, it seems that not many people are interested in this 
proposal. I plan to close this PR first.
If there are any others who want this in place, we can continue to discuss it 
in the RFC thread of this proposal.

Denghui,
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/5938

Reply via email to