RuntimeError while deserializing returnval

[dekz]

I keep getting this almost randomly, I can't nail down what the cause is. It happens with task messages, or Vm responses anything.

There doesn't seem to be any issue with the XML either. I understand it may be a nokogiri error and not exactly RbVmomi.

Anyone else has any issues?

[rlane]

Please paste the SOAP that caused the error. Set debug: true in VIM.connect to see it.

[dekz]

This is what is reported around the exception dump: https://gist.github.com/dekz/fd652d48a6d43009b037

I'll try and wade through and find the debug message.

Here are some that I captured with debug on: https://gist.github.com/dekz/bec973ad82a7e57bc091

[dekz]

So I may have tracked down a possible problem. In the deserializer it attempts to find the class to instantiate, in this case Network. It's picking up a different Network, introduced by another Gem which had defined 'Network' as a module not in its own namespace.

Removing this gem from the Gemfile seems like it fixes that particular problem. Is there a way for deserializer to attempt to namespace deserialize itself to avoid this issue in the future?

[rlane]

The issue is rbvmomi lazy-loads types, so when the deserializer does a const_get of the type name Ruby does a full constant search before calling const_missing. You might be able to fix this by changing https://github.com/vmware/rbvmomi/blob/master/lib/rbvmomi/connection.rb#L211to @loader.get(name) but that doesn't solve the whole problem because the developer could just as well type VIM::Network, which would resolve to the non-rbvmomi Network class. We try to work around this in TypeLoader#preload but that only works completely if rbvmomi is required last.

CC @cdickmann

On Tue, Feb 26, 2013 at 10:45 PM, Jacob Evans [email protected]:

So I may have tracked down a possible problem. In the deserializer it attempts to find the class to instantiate, in this case Network. It's picking up a different Network, introduced by another Gem which had defined 'Network' as a module not in its own namespace.

Removing this gem from the Gemfile seems like it fixes that particular problem. Is there a way for deserializer to attempt to namespace deserialize itself to avoid this issue in the future?

— Reply to this email directly or view it on GitHubhttps://github.com/vmware/rbvmomi/issues/14#issuecomment-14159604 .

[ewendland23]

rlane, could you outline the steps a person should take to perhaps get around errors from lazy-loading? I am trying to use the fantastic rbvmomi gem inside a Rails application, but keep running into the dreaded 'stringify_keys' error message because the wrong Class is being called.