[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699452#comment-14699452
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:
--------------------------------------------

Github user DaanHoogland commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/673#discussion_r37181982
  
    --- Diff: 
api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java ---
    @@ -136,13 +136,13 @@ public String getInstanceName() {
             return instanceName;
         }
     
    -    public Map getDetails() {
    +    public Map<String, String> getDetails() {
    --- End diff --
    
    how about taking the opportunity to change this to 
        public Map<String, String> getDetails() {
            if (this.details == null || this.details.isEmpty()) {
                return null;
            }
            return details;
        }
    Is there any reason to pass through the crazy construct of getting the 
pointer to the first element and casting it back to a map? It seems like very 
unsafe. It becomes even more unsafe when using an instance of a generic type.


> Setting details of VM through API results in removal of all other details 
> except the one passed in API
> ------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8721
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>            Reporter: Anshul Gangwar
>            Assignee: Anshul Gangwar
>
> Setting details of VM through API results in removal of all other details 
> except the one passed in API. We are storing vm details which are not set by 
> user and in this process of setting details all details are getting lost 
> which could lead to other issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to