idisposable.net: a blog about web 2.0, search, Microsoft, Google, and other fun stuff

soap4r vs. Rails: Uninitialized constant when using 1.5.8 with Rails

If the soap4r gem (version 1.5) is breaking your workstation or servers, it might be because there are conflicts between Rails and soap4r both in source code, and in the community. We’ll discuss the source code fix first:

If you are getting this error:

Uninitialized constant when using 1.5.8 with Rails

When running your Rails server (happens with mongrel on my setup), you’ll need to patch a file in the soap gem.

Find the file ns.rb in the soap gem. On OS X, the path should be something like this:

/opt/local/lib/ruby/gems/1.8/gems/soap4r-1.5.8/lib/soap/ns.rb

At around line 19, you should be able to make the following change:


# the dudes who wrote soap4r and the rails folks are battling it out. in the meantime
# you have to apply this patch to prevent soap4r from breaking all of your other projects
# (from http://dev.ctor.org/soap4r/ticket/433)

#KNOWN_TAG = XSD::NS::KNOWN_TAG.dup.update(
#  SOAP::EnvelopeNamespace => 'env'
#)

KNOWN_TAG = {

XSD::Namespace => 'xsd', XSD::InstanceNamespace => 'xsi', SOAP::EnvelopeNamespace => 'env'

}

Viola! You are done. You should apply this to all workstations and servers that have soap4r installed. The alternative is to add:

require 'rubygems'
gem 'soap4r'

to every project that is on your workstation or server. To me, this is an untenable resolution and brings me to the community issues I mentioned above.

If you read the thread here you’ll get a good sense of the nature of the conflict in the community.

Now, I am a relatively new to the Rails scene. I’ve been impressed so far with the professionalism of the community. However, the above issue demonstrates some serious problems.. There is the possibility to completely disable production applications, or interrupt the flow of developers trying to use their local workstations with patches like this.

To start, gem developers like the good people working on soap4r need to ensure compatibility, and make sure that their installation does not essentially break working, fit applications.

This comment on the issue thread says it well:

This is a pretty serious problem for the Ruby community… anyone coming in right now trying out Ruby for the first time in an enterprise context (more likely than not by way of Rails) is going to walk away in frustration.

Beyond that though, what sort of tools can be built it to ensure compatibility? I am no gem expert, but perhaps if there were environment-wide integration tests that would be expected to pass before a gem is installed, these types of frustrating problems would not come up.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*