Folder type is returned as ManagedObjectReference

[akulkarnivnera]

Hi Doug,

It is for com.vmware.vim25.ws.VimStub#retrieveProperties, where managed object reference can be HostSystem, DataStore or VirtualMachine. And the property is parent.

Is this info sufficient ?

[dougm]

Which git revision of govmomi are you using?

[akulkarnivnera]

Its an old one - that I had branched out for vRNI limitations.
Is this no loner an issue ? I'll try getting the latest then.

[dougm]

It was an issue at one point, but it may have only been within a Pull Request (#1800), not in the master branch.

[pambekararkin]

Hi Doug,

We tried with master branch as well, but with master branch govc sim, type property is still incorrectly coming as ManagedObjectReference.
Can you please check and let us know?

cc @akulkarnivnera

Thank you.

Regards,
Priyanka

[dougm]

When running vcsim -trace and the following command:

% govc object.collect /DC0/host/DC0_H0/DC0_H0 parent

The vcsim response is:

<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <WaitForUpdatesExResponse xmlns="urn:vim25">
   <returnval>
    <version>-</version>
    <filterSet>
     <filter type="PropertyFilter">session[ca3e82fd-fa9a-46ee-b4cb-939c1b4f904a]5d919f35-5bd7-4d1e-987a-1c20593e5e04</filter>
     <objectSet>
      <kind>enter</kind>
      <obj type="HostSystem">host-21</obj>
      <changeSet>
       <name>parent</name>
       <op>assign</op>
       <val xmlns:XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" XMLSchema-instance:type="ManagedObjectReference" type="ComputeResource">computeresource-23</val>
      </changeSet>
     </objectSet>
    </filterSet>
   </returnval>
  </WaitForUpdatesExResponse>
 </soapenv:Body>
</soapenv:Envelope>

Sounds like it could be a client-side issue, handling XMLSchema-instance:type="ManagedObjectReference" vs type="ComputeResource".

iirc that was the issue in #1800, on the Go client side.

[malikmarkin]

Hi Doug,
We use the exact same client to fetch the data from the vSphere and we don't see such problem there. Let me share how we get the parent property from real VC and the mocked VC:

Mocked VC:

<propSet><name>parent</name><val xmlns:XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" XMLSchema-instance:type="ManagedObjectReference" type="Folder">group-n29</val></propSet>

Real VC:

<propSet><name>parent</name><val type="Folder" xsi:type="ManagedObjectReference">group-n6</val></propSet>

We uses java based client to parse XML response. Is it possible to get the response in the above format? Do we have to do anything make the mocked vc response in that format?

[dougm]

The differences I see there are:

• namespace declared as "XMLSchema-instance" vs "xsi"
• the order of the twotype attributes

I don't have any Java test case to reproduce what you're seeing, if you can provide that I can take a closer look. Or, if you want to try this patch, it swaps the order of the type attributes:

diff --git a/vim25/xml/marshal.go b/vim25/xml/marshal.go
index c0c0a588..2efdb7a4 100644
--- a/vim25/xml/marshal.go
+++ b/vim25/xml/marshal.go
@@ -497,11 +497,6 @@ func (p *printer) marshalValue(val reflect.Value, finfo *fieldInfo, startTemplat
 		start.Name.Local = name
 	}
 
-	// Add type attribute if necessary
-	if finfo != nil && finfo.flags&fTypeAttr != 0 {
-		start.Attr = append(start.Attr, Attr{xmlSchemaInstance, typeToString(typ)})
-	}
-
 	// Attributes
 	for i := range tinfo.fields {
 		finfo := &tinfo.fields[i]
@@ -524,6 +519,11 @@ func (p *printer) marshalValue(val reflect.Value, finfo *fieldInfo, startTemplat
 		}
 	}
 
+	// Add type attribute if necessary
+	if finfo != nil && finfo.flags&fTypeAttr != 0 {
+		start.Attr = append(start.Attr, Attr{xmlSchemaInstance, typeToString(typ)})
+	}
+
 	if err := p.writeStart(&start); err != nil {
 		return err
 	}

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.