Skip to content
This repository has been archived by the owner on Jul 1, 2021. It is now read-only.

nokogiri attributes workaround support for 1.6.x #32

Merged
merged 2 commits into from
Mar 17, 2014

Conversation

dekz
Copy link
Contributor

@dekz dekz commented Jan 31, 2014

It appears the node['type'] field isn't being populated with later versions of nokogiri (ie 1.6.1). So the condition for finding the type based on this value fails. It can still be accessed via node.attributes which seems to exist in both 1.4.1 to 1.6.1.

This should fix that AnyType VMODL error.
#31

@@ -42,7 +42,13 @@ def initialize conn
end

def deserialize node, type=nil
type_attr = node['type']
if type_attr = node['type']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The empty if block here is weird. I would prefer:

type_attr  = node['type'] || node.attributes['type'].value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, there was some debug in there that just got removed just before I pushed.

Your suggestion will not always work as node.attributes['type'] doesn't always exist.

I'll change this awkward if statement. Thanks

@lamont
Copy link

lamont commented Feb 5, 2014

Fixed my issue perfectly, please accept this pull request


# Work around for 1.5.x which doesn't populate node['type']
# XXX what changed
if node.attributes['type'] and not type_attr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make more sense to invert the two checks? I.e. first check that type_attr is nil and then check for node.attributes['type']?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm maybe.

There's either node['type'] or node.attributes['type']. This PR doesn't attempt to solve why there are discrepancies in the two versions of nokogiri. It's just a quick hack to allow it to work the latest version of nokogiri.

The current version Rbvmomi can support actually has a CVE against it, so the quicker this can be merged the better.

@dekz
Copy link
Contributor Author

dekz commented Feb 20, 2014

Any update on getting this merged in?

@rylarson
Copy link

Can we please get this merged in? This is an extremely low risk fix and I think a lot of people are waiting on this. I have tested this with my setup of vagrant-vsphere + rbvmomi 1.8.1 and nokogiri 1.5.10

rylarson pushed a commit to rylarson/vagrant-vsphere that referenced this pull request Mar 12, 2014
cdickmann added a commit that referenced this pull request Mar 17, 2014
nokogiri attributes workaround support for 1.6.x
@cdickmann cdickmann merged commit 34ecabe into vmware-archive:master Mar 17, 2014
@mkuzmin
Copy link

mkuzmin commented Apr 15, 2014

Any chance to have a new release, or at lease publish this fix in a pre-release build?

@aramprice
Copy link

+1 we could definitely use an official release with the nokogiri fix.

@mmoll
Copy link

mmoll commented Apr 23, 2014

+1 for release

@blysik
Copy link

blysik commented May 2, 2014

A release would be awesome. Yes please.

@djdefi
Copy link

djdefi commented May 12, 2014

+1 for release, this is a pain to deal with

@samling
Copy link

samling commented May 12, 2014

+1 for release

@bdupras
Copy link

bdupras commented May 13, 2014

yet another +1 for release!

@eklein
Copy link

eklein commented May 13, 2014

+1 for release! We're blocked on this too..

@stonith
Copy link

stonith commented May 25, 2014

+1 for a release

@mkuzmin
Copy link

mkuzmin commented Jul 7, 2014

Guys, how do you work around this bug without having a new public rbvmomi release?

I'm using Vagrant and Vagrant-vsphere plugin. The plugin depends on rbvmomi, and that became a real issue. Vagrant is not compatible with nokogiri 1.5 anymore due to other dependencies, so I cannot continue to use the previous rbvmomi version. At the same time, I know no ways how to make the plugin requiring an alternate version of a gem. So I had to publish my own fork of rbvmomi at RubyGems, and maintain an additional fork of the plugin.

@asaenz-vmware
Copy link

+1 for a release
Is there any word at all on when/if this might happen?

@ramrexx
Copy link

ramrexx commented Aug 1, 2014

+1 for release! We are using fog which relies on rbvmomi and are running into the same issue.

@michaelrice
Copy link

This patch fixes the problem for me. Can we please get someone from VMware to release this?

@mmoll
Copy link

mmoll commented Sep 2, 2014

...or create some canoical fork otherwise? This is stalling since half a year 👎

@stonith
Copy link

stonith commented Sep 3, 2014

Reached out to vmware people on Twitter, Hoping we'll get a release soon.

@michaelrice
Copy link

@stonith I did the same, and hit a fling dev directly on irc as well. The feedback I got was pretty positive. I hope to see some results soon too.

@mwrock
Copy link

mwrock commented Sep 22, 2014

I blogged an open letter to vmware and included the lack of releasing this PR as evidence of vmwares's apathy of supporting this library. See the post for response from the gem owner.

This resulted in some "offline" conversations that appeared quite optimistic at first but I am much less optimistic now that weeks have gone by with no action.

I am going to ping some folks to see if anything can be done here but if not, I see no alternative than to fork and create a new authoritative repo and gem otherwise this project is essentially dead.

@cdickmann
Copy link
Contributor

Matt, we have had a very good internal discussion on this, I am quite positive about the outcome. Give us a bit more time as we work through logistics.

@mwrock
Copy link

mwrock commented Sep 22, 2014

Hey thats very encouraging. Thanks @cdickmann. Please keep this thread updated with progress.

@dekz
Copy link
Contributor Author

dekz commented Sep 22, 2014

@mwrock 👍

@mmoll
Copy link

mmoll commented Sep 22, 2014

👍 there are also some other pull requests open, that should be checked after the release.

@michaelrice
Copy link

@mwrock this looks encouraging #50 👯

@hartsock hartsock self-assigned this Sep 22, 2014
@hartsock hartsock added this to the v1.8.2 milestone Sep 22, 2014
@hartsock
Copy link
Contributor

Since this is a new project for me and the turn around is really short, I've cut v1.8.2rc1 as a prerelease and I'll hold onto the gem file and only release to rubygems after I've heard back from a few of you that the gem is acceptable.

I've set up v1.8.3 for a few weeks out. This will give us a chance to review the PRs and decide how to handle them and then release. After that, we'll move to long-term planning.

@bdupras
Copy link

bdupras commented Sep 23, 2014

Excellent news - thanks Shawn!

@mwrock
Copy link

mwrock commented Sep 23, 2014

I will test today. Thanks so much Shawn!

@mkuzmin
Copy link

mkuzmin commented Sep 24, 2014

I briefly tested this version with vagrant-vsphere and found no issues.
Thank you for picking the gem up.

And, Matt, thank you for starting the process!

@hartsock
Copy link
Contributor

Hi folks, based on helpful input on #rbvmomi-dev I've pushed v1.8.2.pre to rubygems please test away. I'll keep the release as a prerelease until next Wednesday to allow for someone to yell stop if needed. I'll follow the same pattern on any subsequent releases.

Going forward I'll build a release issue to capture any conversations about the release itself and not related to any other bugs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet